Libraries & Application Security, Part 3: Unused Libraries

This is the third blog posting in a series about vulnerable libraries. Click here for part one on known vulnerabilities inside libraries. Click here for part two on unknown vulnerabilities inside libraries. 

Most applications use only a very small percentage of the library code they include in their apps. In fact, they frequently don't use some of these libraries at all. The libraries are included because they are a dependency of some other library, and if that library never calls the other library from the parts of the first library actually used by the application, then that other library never gets called at all.

Unused libraries are like weak floors in a part of the house that's inaccessible. There's no risk. Because if an attacker can invoke arbitrary Java code, they already pwn you. However, for the parts of these libraries that your application actually uses, Contrast finds vulnerabilities in this code since its included in Contrast's analysis process. Static analysis can't do that because they ignore libraries, and dynamic analysis is extremely unlikely to find such vulnerabilities because they are so deep in the application execution. 

A Rainbows and Puppies Example

So imagine you use a library called superAwesome4j.jar which has a method that looks like this:

     public void rainbowsAndPuppies( String str ) {
               ... do some stuff
               Runtime.exec( "stuff " + str );
     }

You've effectively created a wrapper around Runtime.exec that makes it invisible to static analysis tools. It's also invisible to the developer. So the innocent developer calls.... 

    SuperAwesome sa = new SuperAwesome();
    sa.rainbowsAndPuppies( request.getParameter( "id" ) );

Look at their code -- it looks safe.  I love rainbows and puppies.  They're Super Awesome.  But they are pwned. And that's something Contrast can help with.

How Contrast Monitors Your Code

Since Contrast monitors the execution of every single line of code that your application executes, regardless of where that code came from, it will easily detect that this seemingly safe rainbowsAndPuppies() library method is subject to command injection. It will then point out exactly where this problem is introduced in this library so you can report the issue to the library provider to get it fixed, and also add mitigating controls in your application, such as strong input validation or simply avoiding this vulnerable method, to ensure that your application is safe, even if the underlying library is vulnerable.

This same capability means Contrast is also great at analyzing third party applications that you don't have the source code for at all. Again, Contrast doesn't care where the code comes from, or whether you even have access to the source code at all. Contrast will point out exactly where in the code each vulnerability is introduced, regardless of its source or pedigree.

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. Speaking of which, thanks for reading.

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