activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <tb...@alumni.duke.edu>
Subject Re: java deserialization vulnerability details for activemq
Date Fri, 11 Mar 2016 13:59:42 GMT
Is there a blacklist somewhere of known gadgets (JAR/version plus specific
classes) so developers can check that they're not whitelisting known
gadgets? Most developers aren't intimately versed in what classes are
exploitable, and most aren't going to take the time to search if it's not
easy, so having a community wiki of some sort that everyone can check on
demand seems like the only way to ensure that ActiveMQ instances get given
a whitelist value other than "*".

Tim
On Mar 10, 2016 2:55 PM, "Moritz Bechler" <bechler@agno3.eu> wrote:

> Am 10.03.2016 um 18:35 schrieb wagonmaster:
> > I'd like to find out some more details about the specific vulnerability
> > motivations behind the whitelist fix for the java deserialization issue.
> I'd
> > like to disambiguate between the addition of the feature for the
> whitelist
> > and the specific java deserialization exploit vectors using the gadget
> > chains.
> >
> > My main goal is to determine whether activemq has any inherent
> exploitable
> > deserialization gadget outside of commons collections.
> >
> > In other words, the whitelist is a precaution and good proactive
> security,
> > but the real 'fix' is the updated dependency. There were no changes to
> any
> > API for activemq that could have been leveraged as a gadget, correct?
> >
> > The implications are that it is minimally sufficient to remediate the
> > commons-collections library alone with a * whitelist for the current
> > releases, and for older releases to just update the commons-collections
> > library. The latter would not provide the safety net the white list
> provides
> > but would remediate the immediate danger.
> >
> > Is my assessment correct?
> >
> Nope, sorry.
>
> Using a very strict whitelist is the only half-way sensible option
> (aside from dropping serialization support altogether).
>
> These gadgets are everywhere, just counting the libraries bundled with
> activemq standalone (didn't check whether they all are used in the
> webconsole - if that's what you are interesed in): there is collections
> as you mentioned, there is spring, there is commons beanutils, all of
> which contain published code execution gadgets. There are the libraries
> that any user of the client may have on the classpath. And, as you
> mentioned it, I had a quick run of my tooling and found another
> unpublished one in one of the dependencies.
>
> These are not going to be fixed on the library side. In fact, I believe
> the commons collections developers have done the community a disservice
> by disabling the deserialization of their "dangerous classes" - as their
> code is really only a very tiny part of the general problem.
>
> Also, btw., don't whitelist as general as sun.* - that contains gadgets
> that allow to bypass the filter altogether.
>
>
> regards
>
> Moritz
>
> --
> AgNO3 GmbH & Co. KG, Sitz Tübingen, Amtsgericht Stuttgart HRA 728731
> Persönlich haftend:
> Metagesellschaft mbH, Sitz Tübingen, Amtsgericht Stuttgart HRB 744820,
> Vertreten durch Joachim Keltsch
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message