Libraries & Application Security, Part 1: Known Vulnerabilities

We're a fan of using open-source frameworks and libraries. It makes sense. It saves time and money when you don't have to write already existing code, especially for universal features or basic functions. It lets developers focus on application specific functionality and business logic. Unfortunately, it also opens up risk to the software development life cycle. The cost of including a library has gone way down. Developers aren't stupid, so they're naturally going to say, 'I don't have to write that code, I'll just use a library to do it.' As a result, they risk pulling in potentially insecure code and running it with the full privilege of their application. That risk is huge, especially if there is a vulnerability in the library, because you've now exposed everything that your application has access to. The OWASP Top Ten says it nicely,

"Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts." OWASP Top Ten

Common Vulnerabilities and Exposures (CVE)

We know you can't easily discover unknown vulnerabilities in the libraries that you are using and the libraries they are dependent on, but we can at least stop using libraries with known vulnerabilities. So if there are common vulnerabilities and exposures already identified, and a fixed version of the library exists, use a version of the library that is already fixed.

Last year Aspect Security teamed up with Sonotype to do a study on The Unfortunate Reality of Insecure Libraries. We found that out of 113 million downloads in the data set we focused on, about one in four of these commonly used Java libraries contained vulnerabilities that were publicly known at the time the library was downloaded. And that's just silly. 

If you are going to use open-source frameworks and libraries, avoid downloading libraries with known vulnerabilities and update them when new updates/patches for the libraries you are already using are released.

Vulnerable Libraries Make Everything Else Vulnerable

Frameworks and libraries are important elements in your application security program. Because if frameworks and libraries fail, there's a chance the safety of your corporate data could be compromised. The risks are high. And it's time more stakeholders realized it, especially security-focused CIOs.

One Way Contrast Can Help

Contrast monitors the versions of all the open source libraries you are using and lets you know when those libraries are out of date, and more importantly, lets you know when those libraries contain known vulnerabilities. Contrast can monitor your library usage throughout your application portfolio, making it quick and easy to identify which applications are using libraries with known vulnerabilities.

The screen shot above is from Contrast. For each open source library you are using, it tells you which version you are using, when each was released, and what is the most recent one available. It also assigns a grade to each library relative to how out of date that library is. So if you are using a very recent version, that library gets an 'A', while very old libraries get an 'F'. In addition, if there are any known vulnerabilities in the library, it automatically gets an 'F' and it provides details about the specific CVE(s) associated with that library and the details for those CVEs.

With this information, it makes it easy for you to identify when you are using libraries with known vulnerabilities, and also helps you upgrade your old libraries in a timely manner. We strongly recommend that you try to use the latest version of each library even if there aren't any known published vulnerabilities in the version of the library that you are using because library providers frequently fix security issues in new releases of their libraries, without publicly acknowledging those security fixes. Thus, there are frequently known vulnerabilities in old versions of libraries, that are known only to the provider, and possibly select others, (including black hats) but not known to you. As such, its prudent to keep up to date as quickly as you can.

** This was the third blog posting in a series about vulnerable libraries. Click here for part two on unknown vulnerabilities inside libraries. Click here for part three on unknown vulnerabilities inside libraries.

Interested in more?

If you're looking for more information, download this free whitepaper (PDF) by Jeff Williams and Arshan Dabirsiaghi. Titled, "The Unfortunate Realities of Insecure Libraries", it ran an experiment with our good friends at Aspect Security & Sonotype. We don't want to give away the ending (we all hate spoilers) we'll just say it's worth the read.