On Thursday, November 01, 2012 09:16:40 Alan Santos wrote:
On Nov 1, 2012, at 9:11 AM, John Mazzitelli <mazz(a)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(a)lists.fedorahosted.org
>>
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel