Ask any application security professional what their top 10 secure coding tips are, and keeping software up to date is probably near to the top of their list.
Dependency updates are basically a really good thing. They address quality issues, improve performance, add functionality and, in many cases, include security fixes to vulnerabilities.
Unfortunately, even as most developers know that they need to update their dependencies when new versions become available, far too many prefer to wait until a “critical” update comes along before they take action. This “If it ain’t broke” attitude is far too common, with updating often relegated to a lower priority in favor of putting out the fires of the day.
Staying on Top of Your Dependencies
When it comes to updating open source dependencies, the task is relegated even farther down on developers’ to-do lists, if it’s featured there at all.
Today, open source components comprise at least 60%-80% of software products, and due to the collaborative nature of the open source community, open source components are built on dependencies, which often include even more dependencies. Software projects typically contain long chains of transitive dependencies, and while keeping track of one project’s dependencies might be tedious but doable, keeping up with a codebase composed of tens or hundreds of modules is impossible to do manually.
Developers tend to forget that in addition to covering the security issues regarding their own code, they need to address the security vulnerabilities in the open source components that they use, including any dependencies. If they don’t know what they are using, developers can’t address the security vulnerabilities that might be affecting their code.
Open source dependencies have become a huge blind spot for developers, which is quite a problem since as open source usage continues to grow, the number of outdated open source dependencies in their systems increases exponentially.
The Untold Truth About Vulnerability Disclosure
When a vulnerability is discovered in an open source project, usually the project maintainers document it and report it to the CVE and the NVD, who then analyze it and publish it once confirmed. However, not everyone follows this practice every time.
Sometimes project maintainers update sub-versions and add fixes for the issues without documenting them. So instead of reporting the vulnerabilities and getting them a CVE ID, they put the fixes in the new versions, counting on users to update their dependencies regularly.
There are a number of reasons that sub-versions are released without documentation of security fixes. Usually it has to do with time or resource management constraints. They may also assume that if they are publishing the update, developers will follow up on the implementation. However, as we know, dependency updates are often neglected.
Protecting Your Dependencies from Unreported Vulnerabilities
Our researchers have compiled a few examples of previously unreported vulnerabilities that were fixed in the following sub-versions without documentation, and have been in contact with the project maintainers.
You might notice that the IDs here start with a “WS” designation, denoting that they are not yet registered with the CVE. We use this for tracking until they are assigned an official CVE ID.
These examples show that while issues are often quickly fixed in subversions, sometimes they aren’t documented or reported as security vulnerabilities.
WS-2019-0350 — InsightSoftwareConsortium’s ITK
Security vulnerability description:
InsightSoftwareConsortium’s ITK versions 4.6rc01 until 5.1b01 suffers from a buffer overflow vulnerability via the GDCM1 interface, which can lead to a denial of service and command execution.
CVSS v3.1 score: 8.1
Affected versions: v4.6rc01–v5.1b01
Fixed version: v5.1rc01
WS-2017-3750 – Jackson-core
Security vulnerability description:
In Jackson-core, versions jackson-core-2.0.0 to jackson-core-2.8.5, jackson-core does not limit the length of its token, which causes a security issue that allows an attacker to remotely flood the server’s logs using invalid data.
CVSS v3.1 score: 8.6
Affected versions: jackson-core-2.0.0–jackson-core-2.8.5
Fixed version: jackson-core-2.8.6
WS-2018-0604 — U-Boot
Security vulnerability description:
U-Boot before v2018.09-rc2 is vulnerable to a buffer overflow which can lead to a potential code execution attack.
CVSS v3.1 score: 8.1
Affected versions: v2015.01-rc1–v2018.09-rc1
Fixed version: v2018.09-rc2
WS-2019-0335 —Tensorflow
Our examples would be incomplete if we did not show a follow-through of the system working.
After contacting Tensorflow maintainers and letting them know about this vulnerability they requested and opened a CVE entry for this vulnerability. It can now be found under the CVE-2019-16778 ID.
Clearly, open source project maintainers are quick to detect and fix any flaws they find, but the added tasks of reporting and documenting the fixes in detail often fall through the cracks. These examples demonstrate that waiting for a critical security alert to update dependencies will probably leave you with quite a few flaws you are unaware of.
Updating Open Source Dependencies: Don’t Forget Your Blind Spots
We trust our open source community to put in the work of finding and fixing vulnerabilities in open source components. Initiatives like GitHub’s Security Lab are working to make the process of reporting vulnerabilities an easier one, which will hopefully reduce the problem of underreporting.
However, it is up to us to go that last mile and stay on top of our updates, because it is always easier to fix issues on time than to deal with the heartbreak of an easily preventable breach afterward.
