RedHat project fights Java vulnerabilities

An Australian RedHat security engineer has developed three initiatives to identify insecure Java archive (JAR) files and prevent them from reappearing in new applications.

Linked gallery: #Ruxcon day 1 in pictures

The initiatives were intended to reduce “JAR security hell” caused by dependencies in Java apps that rely on large numbers of libraries.

David Jorm, a Brisbane-based security engineer with Red Hat's Jboss line told an audience at Ruxcon over the weekend that developers often would not know if their applications contained vulnerabilities.

He explained that Jboss products and their components were vulnerable because they were bundled with dependent JARs but did not use a dependency management system .

This meant that multiple copies and versions of a JAR file could be contained within a single product. 

“In a Linux operating system … if you have a security flaw in a [dynamically-linked] library, all you have to do is patch. But in the Java world, all of the applications bundle their own dependencies together,” Jorm said.

“It's just like everything is statically compiled … if developers aren't manually tracking all the flaws across all the libraries, they will keep pulling in insecure versions from the Maven central repo.”

In March this year, Aspect Security found that 26 percent or 29.8 million library downloads of the 31 most popular Java frameworks from the large Maven central repository contained known vulnerabilities.

Some 1447 projects used a version of Spring that contained a vulnerability (CVE-2010-1662), which resulted in multiple rebuilds that caused “huge overheads”, Jorm said.

One challenge was that there was no minimum standard for data included in manifest.mf within JARs meaning identifying vulnerabilities based on this data would prove "almost impossible", Jorm said.

As one of his three initiatives, Jorm planned to put a list of unpacked JARs into a SQL-based manifest, so packaged JARs could be matched against known vulnerabilities at build time.

He also planned to build a victims database of known vulnerable JARs, using sha-512 fingerprints tied to CVE vulnerability identities — a revival of an abandoned effort by a previous RedHat engineer who included about 50 hashes for vulnerable JARs. 

The third facet was a maven plugin that detected known vulnerable JARs at build time based on the victims database. This checked the canoncial database for vulnerable dependencies using hashes and manifest.mf metadata which balances to help identify vulnerable JARs.

Recently launched commerical tools including Sonatype Insight App Health Check help to identify vulnerable JARs but they are closed source, so methodology is hidden from users.

"We have no idea how they are doing this, or what sort of database they have, or how they are matching them," Jorm. 

As part of its vulnerability response workflow, RedHat now maintains hashes for all components that it ships including those for Maven and those shipped in its own product builds.

"It's quite a usuable set of data, but it needs more community effort," Jorm said.

He asked developers to submit hashes for their own vulnerable JARs.

Copyright © SC Magazine, Australia