Libraries & Application Security, Part 2: Unknown Vulnerabilities

This is part two in a three-part series on vulnerable libraries. Click here to read part one where we discuss known vulnerabilities inside libraries.

Vulnerabilities that haven't been uncovered yet are what most developers and security professionals are focused on. Known vulnerabilities, especially those of a critical nature, get fixed in a prioritized fashion. Low severity vulnerabilities, like those that merely require some clean up of code or those that don't grant access to corporate or user data, get fixed when teams can get around to them, if ever. For libraries, fixing known vulnerabilities means upgrading to the fixed version of the library once the fix is released as discussed in Libraries and Application Security Part One: Known Vulnerabilities.

But what about vulnerabilities in these libraries that no one knows about yet? Most people don't look for them. They simply wait until vulnerabilities are discovered by others, updates are released in the library to fix them, and then they eventually upgrade to use the new library. This leaves your applications at significant risk. It turns out that libraries typically have two types of security issues.

1. Unknown Vulnerabilities
   
   
2. Hazards

Unknown vulnerabilities are what you think they are. A direct vulnerability in the library that should be fixed by the library developer, such as an SQL injection flaw. However, many times there are hazardous methods that behave as intended, but if it not used safely, could introduce a vulnerability in your application. For example, UI libraries allow developers to add JavaScript to a page response. If you pass unvalidated user supplied data to such a method, you'll end up with a Cross-Site Scripting flaw. And this is not the library developers fault. You simply can't pass unvalidated user data to such a method. There are many such methods in open source libraries that are hazardous in various ways, but work as intended, so the library provider can't 'fix' them.

How Can You Find Unknown Vulnerabilities and Hazards in Libraries?

So how do you deal with unknown vulnerabilities and hazardous method calls? YOU have to analyze your application's use of these methods. Do you know what methods are hazardous and which are not? Probably not. And you certainly don't know which are directly vulnerable. One thing library providers could do is to make it clear in their documentation which methods are hazardous, and thus require proper input validation, output encoding, or some level of trust in the data BEFORE calling the method. However, most library vendors DO NOT provide this level of documentation with their libraries, even though they should.

So how do you analyze your application's use of library calls? You could do code analysis by hand, but the code reviewer would have to know which methods are hazardous and which are not. You could try static analysis tools, but they don't know which library methods are hazardous or not, because they don't have access to the source code for the library. You could try external scanning tools, but they will only discover unsafe use of a hazardous call if they can figure out how to send a successful attack payload into the correct parameter AND detect a response that indicates a successful attack. So you might find a few XSS flaws this way, but its going to be tough for such tools to find most of these kinds of flaws.

How Contrast Can Help

Contrast, on the other hand, can find unsafe use of these hazardous methods with ease, and even discover previously unknown vulnerabilities, because Contrast analyzes the running code regardless of whether you have access to the source code or not. Yes, that's right, libraries and frameworks, as well as proprietary or third-party applications. Contrast just doesn't care. It will detect that certain unsafe data is being passed into a hazardous method and detect the SQL Injection, Command Injection, XSS, unsafe instantiation of weak crypto, or whatever the flaw is, just like it can do in all other parts of the application. Once Contrast has found such an issue, you can easily fix your code to make safe use of this hazardous method, regardless of whether you knew the method was hazardous to use or not in the first place.

And if it turns out that Contrast detects that a method is actually vulnerable (not just hazardous), and should be fixed by the vendor (e.g. because it has some kind of injection flaw), you can make your use of this method safe in the mean time AND report the issue to the library provider to get it fixed.

Because Contrast tells you the exact line of code where the vulnerability exists, it allows you to not only prove to the code owner that there is indeed a problem, but exactly where the problem is so they can fix it quickly. This allows your open source and 3rd party code providers to much more quickly validate the security issues you report to them, and speeds their ability to fix the problem and provide you with patched software that you can deploy to reduce your risk of using this 3rd party provided code.

The example pictured above shows a set of vulnerabilities on the left found by Contrast in an application. The selected vulnerability, whose details are displayed on the right, describes an XPath Injection vulnerability. If Contrast finds unsafe use of a hazardous library call, or a new, previously unknown, vulnerability in the library itself, it will report that vulnerability along with all the other vulnerabilities found in the current application. 

Imagine a library provider uses XPath to do queries againsts data managed by that library and the library provider never expects a developer to pass unvalidated data to this query method. As such, this method is hazardous. If you only pass trusted or properly validated data to this method, there's no problem. But if you blindly pass user-supplied data to this method, you have an XPath Injection flaw.

With the information Contrast provides, you can now make use of this method safe. If you feel that the library provider should have made this method safe for use with ANY data, including unvalidated user supplied data, you can report this issue to the provider and if they agree, they might be able to fix this method so its safe no matter what. Regardless of whether they fix it or not, you've been able to make your application safe.

Proactive analysis is necessary to find unknown vulnerabilities and unsafe use of hazardous methods before others do. Your development process needs to allow your developers to find and eliminate security flaws early in the code creation cycle, ideally before your developers even check in new code for the first time. The earlier in your software development lifecycle security flaws are found and eliminated, the cheaper it is for your organization. Finding and eliminating vulnerabilities before they get into production is critical to avoiding their discovery and exploit by attackers before your own team is aware of them.

But you don't have to just take our word for it. Watch this short video to learn how you can get the Contrast dashboard up and running in eight minutes flat. That's right: Eight. Minutes. Flat.

** This is part two of a three-part series. Click here to read part one on known vulnerabilities and exploits. Part three is focused on vulnerabilities inside unused portions of libraries.

Because Three Parts Just Isn't Enough

So there is the three-part series about libraries and application security, covering the basics of known and unknown vulnerabilities, and unused portions of used libraries.

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.