RedHat project fights Java vulnerabilities

Powered by SC Magazine
 

Aussie security boffin builds vulnerability database to track flawed JARs.

View larger image View larger image View larger image

See all pictures here »

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

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 .

Credit: SC

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


 
 
 
Top Stories
IBM, NEC picked for major NSW Transport deals
Final contract negotiations begin.
 
Govt proposes crackdown on ISPs over piracy
Wants new legal powers for copyright industry.
 
Westpac interim CIO resigns
Group CIO yet to be appointed.
 
 
Sign up to receive iTnews email bulletins
   FOLLOW US...
Latest Comments
Polls
What is delaying adoption of public cloud in your organisation?







   |   View results
Lock-in concerns
  30%
 
Application integration concerns
  3%
 
Security and compliance concerns
  27%
 
Unreliable network infrastructure
  9%
 
Data sovereignty concerns
  22%
 
Lack of stakeholder support
  3%
 
Protecting on-premise IT jobs
  4%
 
Difficulty transitioning CapEx budget into OpEx
  3%
TOTAL VOTES: 1013

Vote