Subscribe
As open source development has become mainstream, developers have been able to benefit from a growing number of application development and security solutions that help them build secure, high-quality software fast. Several new open source vulnerability management (a.k.a. software composition analysis) solutions have emerged, and at first glance, it can be hard to determine what differentiates them—at some level, they all claim to help you catalog your open source and show you information about the current known vulnerabilities.
However, there are differences, and as with any security solution, effectiveness at detecting the security risks is key. In this post, I’ll try to explain the different approaches to open source vulnerability detection, the pros and cons of each, and why we combine them to maximize the accuracy of Black Duck.
Open source discovery: The key to accuracy
If you don’t know what open source components you’re using, you can’t protect yourself from vulnerabilities in those components. It’s that simple. So the ability to accurately discover all the open source in your running systems is essential. Black Duck’s multifactor discovery feature uses combined information from package managers and file scanning to maximize accuracy.
Package manager declarations: A good starting point
Package managers are used to help manage dependencies both for those building software as well as for anyone simply deploying software. You can evaluate package manager information in two contexts:
- Build specification. Package managers are generally customized for a specific programming language. Package manifest files (for example, Maven POM files) specify what components to include and where (public or private repository) to obtain them.
- Software installation. This language-independent mechanism orchestrates installation of software packages, as well as any other packages they depend on.
When package manager data is available, the information is easily accessible and quite accurate. On the other hand, it's not always available and is easily spoofed, so this is just a starting point for Black Duck.
File signature scanning: Finds “hidden” open source
Although you can get a lot of information from package managers, they often cannot provide the complete picture—neither are all dependencies declared during a build, nor is all software installed using a package manager.
For example, Docker containers can also “hide” components by bypassing the package manager altogether. If you examine a typical dockerfile (the build file of the Docker image), you’ll often find that it’s built with the following command:
make install
Make install (as opposed to yum, rpm, or dpkg install) goes around the package manager, leaving it blind to the image contents, as the exploit examples below demonstrate.
By contrast, file signature scanning (using a hashing algorithm to compute a set of unique “signatures” for source and binary files) can be used with almost every programming language or environment, and is able to recognize components both as source and binaries. The signatures each represent anywhere from small snippets of code within a file to arbitrarily large directories full of data. By analyzing file and directory contents, signature scanning can detect “undeclared” components hiding in the codebase.
The algorithms for generating and utilizing signatures are complicated and may, in some cases, lead to ambiguous or inaccurate results. While disambiguation used to require someone to review the initial results, Black Duck’s “fuzzy matching” logic automates and streamlines this process by examining a variety of directory and file attributes.
The proof of the pudding: Finding vulns
The package manager method is significantly easier to implement, so it’s no surprise that many solutions only support that approach. Perhaps they figure that close enough is good enough.
We don’t.
To demonstrate why package manager data alone does not provide sufficient vulnerability protection, we tested the accuracy of package-manager-only vs. multifactor discovery with Black Duck.
As a basis for our test, we used easily-obtained published exploits. These days many published exploits even come with pre-built vulnerable Docker systems to attack. These pre-built systems are designed to be vulnerable to specific CVEs.
Our test approach was straightforward:
- Scan the vulnerable Docker images with both methodologies.
- See which of the methods find the relevant vulnerability.
We ran a test across eight of these example vulnerability/exploit systems, and as you will see in the video and summaries below, the results speak for themselves.
CVE-2017-5638 (The "Equifax" Vulnerability)
Component: Apache Struts
CVSS v3 Score: 10.0 Critical
Exploit: https://github.com/jrrdev/cve-2017-5638
Description: The Jakarta Multipart parser in Apache Struts 2 2.3 before 2.3.32 and 2.5.x before 2.5.10.1 mishandles file upload, which allows remote attackers to execute arbitrary commands via a #cmd= string in a crafted Content-Type HTTP header, as exploited in the wild in March 2017.
Signature Scanning Method: Detected
Package Manager Method: Not Detected
CVE-2017-7494 (a.k.a. SambaCry)
Component: Samba
CVSS v3 Score: 9.8 Critical
Exploit: https://github.com/opsxcq/exploit-CVE-2017-7494
Description: All versions of Samba from 3.5.0 onward are vulnerable to a remote code execution vulnerability, allowing a malicious client to upload a shared library to a writable share, and then cause the server to load and execute it.
Signature Scanning Method: Detected
Package Manager Method: Not Detected
Component: ProFTPD
CVSS v2 Score: 10.0 HIGH
Exploit: https://github.com/t0kx/exploit-CVE-2015-3306
Description: The mod_copy module in ProFTPD 1.3.5 allows remote attackers to read and write to arbitrary files via the site cpfr and site cpto commands.
Signature Scanning Method: Detected
Package Manager Method: Not Detected
Component: Elasticsearch
CVSS v2 Score: 7.5 HIGH
Exploit: https://github.com/t0kx/exploit-CVE-2015-1427
Description: The Groovy scripting engine in Elasticsearch before 1.3.8 and 1.4.x before 1.4.3 allows remote attackers to bypass the sandbox protection mechanism and execute arbitrary shell commands via a crafted script.
Signature Scanning Method: Detected
Package Manager Method: Not Detected
Component: PHPMailer
CVSS v3 Score: 9.8 Critical
Exploit: https://github.com/opsxcq/exploit-CVE-2016-10033
Description: PHPMailer before its version 5.2.18 suffer from a vulnerability that could lead to remote code execution (RCE). The mailSend function in the isMail transport in PHPMailer, when the Sender property is not set, might allow remote attackers to pass extra parameters to the mail command and consequently execute arbitrary code via a \" (backslash double quote) in a crafted From address.
Signature Scanning Method: Detected
Package Manager Method: Not Detected
Component: NTP
CVSS v3 Score: 7.5 High
Exploit: https://github.com/opsxcq/exploit-CVE-2016-7434
Description: The read_mru_list function in NTP before 4.2.8p9 allows remote attackers to cause a denial of service (program failure) via a crafted mrulist query. Ntpd suffer from a null pointer reference which is possible to trigger a program failure in the application. According to NTP.org, "If ntpd is configured to allow mrulist query requests from a server that sends a crafted malicious packet, ntpd will cause a program failure on receipt of that crafted malicious mrulist query packet."
Signature Scanning Method: Detected
Package Manager Method: Not Detected
Component: Spring Security OAuth
CVSS v3 Score: 8.8 High
Exploit: https://hub.docker.com/r/vulnerables/cve-2016-4977/
Description: When processing authorization requests using the whitelabel views in Spring Security OAuth 2.0.0 to 2.0.9 and 1.0.0 to 1.0.5, the response_type parameter value was executed as Spring SpEL which enabled a malicious user to trigger remote code execution via the crafting of the value for response_type.
Signature Scanning Method: Detected
Package Manager Method: Not Detected
Component: Roundcube
CVSS v3 Score: 7.5 High
GitHub Repo: https://github.com/t0kx/exploit-CVE-2016-9920
Description: steps/mail/sendmail.inc in Roundcube before 1.1.7 and 1.2.x before 1.2.3, when no SMTP server is configured and the sendmail program is enabled, does not properly restrict the use of custom envelope-from addresses on the sendmail command line, which allows remote authenticated users to execute arbitrary code via a modified HTTP request that sends a crafted e-mail message.
Signature Scanning Method: Not Detected*
Package Manager Method: Not Detected
* In this case, scanning detected some evidence of the component, but that evidence was below thresholds for reporting. These thresholds are in place to minimize the incidents of “false positives.” Our team continuously reviews scan accuracy and tunes our algorithms to provide the most reliable results possible.
Look beyond package declarations
When package manager data is present and untampered with, the information can be easy to aggregate and reasonably accurate. However, it often doesn’t give you a complete list of components. That lack of visibility can increase your security risk. These results show that combining multiple approaches to fully and accurately identify open source components in use is essential.
We are constantly finding new ways to identify vulnerabilities. With every new release, we strive to use these new approaches so that no open source vulnerability remains unseen at the bottom of the Pandora’s box.
Continue Reading
