Proposal: mandatory versioning metadata for modules

[David Jorm]

Hi Pascal

After various discussions on both this list and elsewhere, I've 
investigated several options to improve the bad-jar matching, including 
the technique outlined in that paper. Unfortunately I don't think the 
anchored signature matching technique will work, since the anchored 
signature of a vulnerable jar may not differ from that of a patched jar. 
Many security patches don't modify any method signatures, just the logic 
inside a method. Cases where other patches have been applied that do 
change method signatures, but don't address the security flaw, would 
also result in false negatives with this technique.

So far the best candidate solution I have is to:

1) Explode the jar
2) Remove META-INF elements
3) Re-package jar
4) Checksum re-packaged jar
5) [Phase 2: somehow handle one jar being a superset of another]

I intend to try this in the next version of the tools I'm developing. 
That said, mandatory version metadata is still helpful for both this and 
other use cases.

Thanks
David

On 10/25/2012 08:53 PM, Pascal Rapicault wrote:
> Like you I'm a bit surprised by the optional nature of the version number.
> However even if the version was made mandatory I don't think this would
> suffice to identify jars (btw, another case of jar modification is shading
> (the jar is copied into another one, and sometimes the package renamed)).
> For example people could forget to update the jar version or do it
> deliberately (because they don't want to update dependent libs), or simply
> strip it when aggregating jars.
>
> There is a lot of research papers talking about finding similarities in
> jars, but the one that I found to be the most robust to do this kind of
> work is http://dl.acm.org/citation.cfm?doid=1985441.1985468
>
> HTH
>
> Pascal
>
>
> On Thu, October 25, 2012 01:03, David Jorm wrote:
>> Hi All
>>
>> I am currently working on a system for tracking JAR files that expose
>> known security flaws, identifying them by checksums or metadata. In short,
>> both of these mechanisms have shortcomings. Checksums of JAR files provide
>> zero false positives, but have huge scope for false negatives. Whenever a
>> JAR is re-compiled, bits in the JAR change and the checksum changes.
>> Metadata is unreliable, as META-INF/MANIFEST.MF does not require the
>> inclusion of title and version elements. A more detailed overview is
>> available here [0]. To give an example of the problem I'm attempting to
>> solve, Spring 2.5.6 exposes a remote code execution flaw. It is fixed in
>> Spring 2.5.6.SEC01. I want to be able to distinguish between 2.5.6 and
>> 2.5.6.SEC01 to identify whether a system is deploying the vulnerable JAR.
>> I can't
>> just use a checksum of the file, because if anyone recompiles it, bits
>> change. I also can't rely on the MANIFEST.MF, because it may or may not
>> include any version data; it may not even identify the title of the
>> component as "Spring".
>>
>> The Jigsaw project offers a great opportunity to solve this problem.
>> However, I note in the documentation [1]:
>>
>> "A /module/ is a collection of Java types (/i.e./, classes and interfaces)
>> with a name, an optional version number, and a formal description of its
>> relationships to other modules."
>>
>> The problem here is "optional" version number. What I'm trying to achieve
>> is mandatory minimal version metadata. What do people think about making
>> version number a requirement for Jigsaw modules? Would that be feasible
>> and if so would it be desirable?
>>
>> Thanks
>> --
>> David Jorm / Red Hat Security Response Team
>>
>> [0] http://www.slideshare.net/davidjorm/tracking-vulnerable-jars
>> [1] http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01
>>
>