Pandora’s box: Exploits show package manager blind spots

Sep 14, 2017 / 5 min read

Table of Contents

Open source discovery: The key to accuracy
The proof of the pudding: Finding vulns
Look beyond package declarations

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.