Proposal: mandatory versioning metadata for modules

[David Jorm]

The system is aimed primarily at security, but a similar approach can be 
used for other aspects of component management, e.g. license auditing. 
You're absolutely right that even with mandatory version metadata, an 
attacker could create a modified version of the JAR that intentionally 
does not identify as being vulnerable. That's a problem with no ultimate 
solution, though. In the malware world you have all kinds of 
polymorphic, obfuscated code designed to defy any kind of 
identification. Anti virus companies are fighting this arms race with 
malware authors, but I have no intention of getting involved in that 
battle. Furthermore, if you're consuming components supplied by an 
attacker, they're likely to include backdoors or other things, and 
you've got bigger problems to contend with.

I'm more interested in the case where a person consumes a component from 
a trusted source, for example the maven central repo, but is not aware 
that it exposes a known security flaw. Doing some partial contextual 
hashing of the JAR bits is another approach I am currently 
investigating. This will probably work for most simple re-compiles, but 
where people maintain their own branches with backported patches, it 
would run into problems, and simply identifying the version by metadata 
would be preferable.

All that is to say: yes, this isn't a fool-proof mechanism, but it would 
be an improvement.

Thanks
David

On 10/25/2012 03:32 PM, Eric Johnson wrote:
> Is this a security system, or a JAR management system?
>
> If it is merely a management system, I can see how your proposal to 
> require version numbers might work (although it seems to be assuming 
> that people will remember to update version numbers).
>
> If it is a security system, then I think you need to investigate the 
> threat model a little more, because it might not be sufficient for a 
> JAR to self-identify as a specific version, since a rogue actor will 
> simply do that to defeat your code. In that case, to derail the rogue 
> actor, don't you need to do a SHA-512 or other signature of the 
> interesting bits of a JAR file (some sort of c14n process that 
> eliminates the spurious bit twiddling that otherwise occurs upon 
> recompile)?
>
> Eric.
>
> On 10/24/12 10:03 PM, 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
>