Access member only content, take part in discussions with comments on blogs, news and reviews and receive all the latest security industry news directly to your inbox. Join now for free.
Processing registration... Please wait.
This process can take up to a minute to complete.
A confirmation email has been sent to your email address - SUPPLIED EMAIL HERE. Please click on the link in the email to verify your email address. You need to verify your email before you can start posting.
If you do not receive your confirmation email within the next few minutes, it may be because the email has been captured by a junk mail filter. Please ensure you add the domain @scmagazine.com.au to your white-listed senders.
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 .
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
To begin commenting right away, you can log in below or register an account if you don't yet have one. Please read our guidelines on commenting. Offending posts will be removed and your access may be suspended. Abusive or obscene language will not be tolerated. The comments below do not necessarily reflect the views or opinions of SC Magazine, Haymarket Media or its employees.