Incorporating known-vulnerable JAR scanning into RHQ

Lukas Krejci lkrejci at redhat.com
Thu Nov 1 13:48:00 UTC 2012


On Thursday, November 01, 2012 09:16:40 Alan Santos wrote:
> On Nov 1, 2012, at 9:11 AM, John Mazzitelli <mazz at redhat.com> wrote:
> > This could be added as a separate plugin that injects a separate child
> > service until the top platform resource. This simple child resource could
> > have a simple operation on it "check for known vulnerabilities" which
> > could be scheduled to periodically run. The operation results could
> > return the number of vulnerabilities found and where they are.  There
> > could also be metrics - so you could define, say, a metric "Known
> > Vulnerabilities" that is collected every 24 hours - it would do the same
> > thing as the operation.
> > 
> > There are a few things we could do here, but I think this functionality
> > could very easily be added by simply writing and deploying an agent
> > plugin. We wouldn't have to code anything into core RHQ at all.

While filesystem traversal and computing hashes is no rocket science, I don't 
think we would be able to reuse the code from the drift subsystem that I think 
charles was refering to which is the only objection I have against the agent 
plugin approach - we'd be reimplementing stuff that already exists in our 
codebase. Even though if David goes ahead with the partial hashes, the code we 
have in drift wouldn't probably apply anyway.

> Rather than add it to it's own plugin, could it be added as a feature for
> specific plugins? It seems as though it could be optimized for certain
> types vs. a very large scan.

While the plugin could be configured to scan only certain directories (to avoid 
the "large scan"), I am not a fan of this approach either, because we'd not be 
able to take advantage of the automatic "association" of the vulnerability to 
the affected server/service by the means of the inventory tree hierarchy.

The plugin could instead inject the new resource type under our selected 
resource types in different plugins we develop and 3rd party plugins could 
define their own injection points in their plugin descriptors if they wished to 
include this functionality (this would require the affected resource components 
to probably implement some new interface in the code so that the plugin would 
be able to figure out the base directories to base the scan on).

> 
> Also, let's not synchronize a database. It seems like a service is a much
> better option with less overhead for users, no need to worry about being
> out of date because the last synchronization failed or tool around with
> schema changes.
> > ----- Original Message -----
> > 
> >> Hi All
> >> 
> >> I have recently been working on some tools to identify
> >> known-vulnerable jars at build time. Details on the whole tool chain
> >> are here:
> >> 
> >> http://www.slideshare.net/davidjorm/tracking-vulnerable-jars
> >> 
> >> Part of this is the victims DB (http://victi.ms), a canonical
> >> database of known-vulnerable jars. I recently presented this
> >> material at a security conference, and one attendee who is a big
> >> RHQ/JON user raised the suggestion of incorporating this into RHQ.
> >> The idea would be for RHQ to (optionally) synchronize the victims DB
> >> locally, and use it to scan deployed user applications on all the
> >> servers it manages. It would then (as per configuration) trigger
> >> alerts when it finds a deployed app with a known-vulnerable jar in
> >> it. Once this kind of feature was in RHQ, you could easily plug in a
> >> database to identify code licensing in jars or other things.
> >> 
> >> I spoke to Charles Crouch about this and he mentioned that RHQ
> >> already has code to scan dirs and collect md5s. That would just need
> >> to be modified to collect SHA1/SHA512 checksums and compare them to
> >> the victims DB.
> >> 
> >> I'm currently working on refining the mechanism used to identify
> >> known-vulnerable jars. Rather than relying on complete jar checksums
> >> and metadata, I want to do partial contextual hashing of the jar
> >> contents. Once this is working we should have much more accurate
> >> matching of vulnerable jars, and I imagine we'd be able to
> >> demonstrate something like "1 in 50 user-deployed apps is
> >> vulnerable" - probably even more than that. I don't think we should
> >> build this feature until that refinement of the mechanism is
> >> complete on my side, but I wanted to start a discussion about this
> >> anyway and see what people think about adding this feature?
> >> 
> >> Thanks
> >> --
> >> David Jorm / Red Hat Security Response Team
> >> 
> >> _______________________________________________
> >> rhq-devel mailing list
> >> rhq-devel at lists.fedorahosted.org
> >> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> > 
> > _______________________________________________
> > rhq-devel mailing list
> > rhq-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
> 
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel


More information about the rhq-devel mailing list