The *OTHER* Security Problem with Your Insecure Libraries

In early 2012, we published a study called "The Unfortunate Reality of Insecure Libraries" where we found that just about everyone is downloading libraries with known vulnerabilities -- bad ones. That's a real problem and you need a way to stay on top of it across your portfolio -- like using Contrast™.  But there's another security problem with insecure libraries that's potentially more dangerous.

Library Security Hazards

Libraries contain a huge variety of classes and methods. Some of these are innocuous, regardless of how they are called. Others always cause vulnerabilities. And still others are extremely powerful and can cause great damage if they are invoked incorrectly or with untrusted data -- these are the "hazards."

The problem is that nobody knows which methods are dangerous and which are safe. When we find a clear vulnerability, it's easy to give guidance to everyone how to avoid the problem. But what about those methods that are just "hazardous" not inherently dangerous?  We need to get developers great information about the security properties of methods, so they can make informed decisions about what precautions they need to make before invoking them.

The Library Study

We set out to try to identify methods that have interesting security properties. We fuzzed these methods and checked to see if anywhere during the method invocation (and all the internal nested calls) anything interesting happened. We looked for things like:

• Uses insecure hash or crypto algorithm
• Invokes a dangerous API with a parameter to the studied method
• Propagates untrusted data to the object, parameters, or return

We found some interesting things that we'll be talking about in our upcoming talk at JavaOne.

How Does This Affect Your Code?

Let's say you're using a popular library like Log4j or HttpComponent. Imagine that there is a hazardous call in that library. Let's imagine that this method is named something innocuous, like setConfigurationDefaults().  But it turns out that under the hood, this method calls some other methods (perhaps even dependent components) and eventually that data gets sent to a call to Runtime.exec().  You just made your application vulnerable to what's known as "Remote Code Execution" and an attacker could use it to take over your entire application server.

How could you know? Well, that's the problem. Until Contrast™, there was no good way to find out. Static analysis tools don't trace execution through libraries, so those tools won't work.

Contrast™ traces data and control flow through your *entire* application, including libraries. If untrusted data reaches a hazardous method -- even deep within your application's framework or libraries -- Contrast™ will detect it and report it back to you.

Knowing the Known Vulnerabilities Isn't Enough

So just because you're using the latest version of a library, and even if you've determined that there are no known vulnerabilities, you have to have insight into the "unknown" vulnerabilities.  And that's where Contrast™ is unmatched.

Want to harden your use of libraries and components?