You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Bernd Eckenfels <ec...@zusammenkunft.net> on 2015/11/06 22:25:53 UTC
[collection][security] InvokerTransformer missused in java object
serialisation exploits
ello,
I came across this article:
http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
It describes attacks against common Java applications with
pre-authentication requests using malicious Java Object serialisation.
It builds upon the work of Gabriel Lawrence (@gebl) and Chris Frohoff
(@frohoff) (presented on January 28th, 2015, “Marshalling Pickles”
given at AppSecCali)
http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles
The ysoserial tool has some sample payloads, two use
commons-collection oac.collections.functors.InvokerTransformer. *
https://github.com/frohoff/ysoserial/tree/master/src/main/java/ysoserial/payloads
The class itself is rather handy to break out of the readObject()
chains to execute arbitrary methods.
I do'nt recall any discussion here about this
class. Is this currently handled/reported? Of course the more general
problem is using serialisation with untusted peers, and if
commons-collection fixes this, there might still be other vectors, but
still I think it would be good to do something against that "bad press"?
Gruss
Bernd
* Another payload uses org.codehaus.groovy.runtime.MethodClosure from
Groovy or some sring AutoWire Stuff.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by James Carman <ja...@carmanconsulting.com>.
Yes, I guess it should be prevented. Duh!
On Sun, Nov 8, 2015 at 2:16 PM Mark Thomas <ma...@apache.org> wrote:
> On 08/11/2015 19:13, James Carman wrote:
> > If they can execute Runtime.exec then they can execute System.setProperty
>
> Yes. But the point you seem to seem to be missing is that if the system
> property is set such that this attack is blocked, they can't use the
> attack to change the system property and unblock it.
>
> Mark
>
>
> > On Sun, Nov 8, 2015 at 2:11 PM James Carman <ja...@carmanconsulting.com>
> > wrote:
> >
> >> System.setProperty()
> >>
> >>
> >> On Sun, Nov 8, 2015 at 2:10 PM Thomas Neidhart <
> thomas.neidhart@gmail.com>
> >> wrote:
> >>
> >>> On 11/08/2015 07:51 PM, James Carman wrote:
> >>>> Couldn't they use the same attack vector to set a system property
> also?
> >>> I
> >>>> do believe that would be possible
> >>>
> >>> for this you need a way to execute code via a de-serialized class.
> >>> Right now, the simplest way to do so is via the InvokerTransformer.
> >>>
> >>> There are surely other ways to do so, but if the only available way is
> >>> blocked (i.e. InvokerTransformer can not be deserialized), a remote
> >>> attacker cannot set a system property via this attack vector.
> >>>
> >>> btw. setting a system property can also be restricted by a
> >>> SecurityManager.
> >>>
> >>> I am -1 on a programmatic interface, and for the 4.X branch I propose
> to
> >>> remove the serialization support completely.
> >>>
> >>> Thomas
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by Mark Thomas <ma...@apache.org>.
On 08/11/2015 19:13, James Carman wrote:
> If they can execute Runtime.exec then they can execute System.setProperty
Yes. But the point you seem to seem to be missing is that if the system
property is set such that this attack is blocked, they can't use the
attack to change the system property and unblock it.
Mark
> On Sun, Nov 8, 2015 at 2:11 PM James Carman <ja...@carmanconsulting.com>
> wrote:
>
>> System.setProperty()
>>
>>
>> On Sun, Nov 8, 2015 at 2:10 PM Thomas Neidhart <th...@gmail.com>
>> wrote:
>>
>>> On 11/08/2015 07:51 PM, James Carman wrote:
>>>> Couldn't they use the same attack vector to set a system property also?
>>> I
>>>> do believe that would be possible
>>>
>>> for this you need a way to execute code via a de-serialized class.
>>> Right now, the simplest way to do so is via the InvokerTransformer.
>>>
>>> There are surely other ways to do so, but if the only available way is
>>> blocked (i.e. InvokerTransformer can not be deserialized), a remote
>>> attacker cannot set a system property via this attack vector.
>>>
>>> btw. setting a system property can also be restricted by a
>>> SecurityManager.
>>>
>>> I am -1 on a programmatic interface, and for the 4.X branch I propose to
>>> remove the serialization support completely.
>>>
>>> Thomas
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by James Carman <ja...@carmanconsulting.com>.
If they can execute Runtime.exec then they can execute System.setProperty
On Sun, Nov 8, 2015 at 2:11 PM James Carman <ja...@carmanconsulting.com>
wrote:
> System.setProperty()
>
>
> On Sun, Nov 8, 2015 at 2:10 PM Thomas Neidhart <th...@gmail.com>
> wrote:
>
>> On 11/08/2015 07:51 PM, James Carman wrote:
>> > Couldn't they use the same attack vector to set a system property also?
>> I
>> > do believe that would be possible
>>
>> for this you need a way to execute code via a de-serialized class.
>> Right now, the simplest way to do so is via the InvokerTransformer.
>>
>> There are surely other ways to do so, but if the only available way is
>> blocked (i.e. InvokerTransformer can not be deserialized), a remote
>> attacker cannot set a system property via this attack vector.
>>
>> btw. setting a system property can also be restricted by a
>> SecurityManager.
>>
>> I am -1 on a programmatic interface, and for the 4.X branch I propose to
>> remove the serialization support completely.
>>
>> Thomas
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by James Carman <ja...@carmanconsulting.com>.
System.setProperty()
On Sun, Nov 8, 2015 at 2:10 PM Thomas Neidhart <th...@gmail.com>
wrote:
> On 11/08/2015 07:51 PM, James Carman wrote:
> > Couldn't they use the same attack vector to set a system property also? I
> > do believe that would be possible
>
> for this you need a way to execute code via a de-serialized class.
> Right now, the simplest way to do so is via the InvokerTransformer.
>
> There are surely other ways to do so, but if the only available way is
> blocked (i.e. InvokerTransformer can not be deserialized), a remote
> attacker cannot set a system property via this attack vector.
>
> btw. setting a system property can also be restricted by a SecurityManager.
>
> I am -1 on a programmatic interface, and for the 4.X branch I propose to
> remove the serialization support completely.
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by Thomas Neidhart <th...@gmail.com>.
On 11/08/2015 09:36 PM, James Carman wrote:
> Oh nasty! I must've met, this is quite a fascinating exploit. I'm going to
> do some digging later today when I am at my computer.
I just figured that the xalan code already does have a system property
to prevent translets from being de-serialized:
public final static String DESERIALIZE_TRANSLET =
"jdk.xml.enableTemplatesImplDeserialization";
so a similar solution what we are going to do for collections.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by James Carman <ja...@carmanconsulting.com>.
Oh nasty! I must've met, this is quite a fascinating exploit. I'm going to
do some digging later today when I am at my computer.
On Sun, Nov 8, 2015 at 3:34 PM Thomas Neidhart <th...@gmail.com>
wrote:
> On 11/08/2015 09:11 PM, James Carman wrote:
> > How did we get to the point where someone could invoke arbitrary
> bytecode?
>
> Take a look at class TemplatesImpl in
> com.sun.org.apache.xalan.internal.xsltc.trax which is part of the oracle
> and openjdk jre.
>
> It is serializable and can load so called Translets which are stored as
> byte[] and will be loaded once the newTransformer method is invoked.
>
> So an attacker can store byte code in the array of a serialized
> TemplatesImpl object and force its execution via the InvokerTransformer.
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by Thomas Neidhart <th...@gmail.com>.
On 11/08/2015 09:11 PM, James Carman wrote:
> How did we get to the point where someone could invoke arbitrary bytecode?
Take a look at class TemplatesImpl in
com.sun.org.apache.xalan.internal.xsltc.trax which is part of the oracle
and openjdk jre.
It is serializable and can load so called Translets which are stored as
byte[] and will be loaded once the newTransformer method is invoked.
So an attacker can store byte code in the array of a serialized
TemplatesImpl object and force its execution via the InvokerTransformer.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by James Carman <ja...@carmanconsulting.com>.
How did we get to the point where someone could invoke arbitrary bytecode?
On Sun, Nov 8, 2015 at 2:47 PM James Carman <ja...@carmanconsulting.com>
wrote:
> Runtime.exec can be prevented though
>
> On Sun, Nov 8, 2015 at 2:31 PM Thomas Neidhart <th...@gmail.com>
> wrote:
>
>> On 11/08/2015 08:20 PM, James Carman wrote:
>> > I think this entire thing can be prevented with a security manager and a
>> > proper policy in place. Nobody does that, though
>>
>> You cannot prevent the use of reflection for public methods via a
>> SecurityManager.
>>
>> If you then look at the different provided payloads you can see that an
>> attacker can inject arbitrary bytecode that is being loaded.
>>
>> How would you prevent that such code is able to do anything harmful,
>> especially considering that it is being executed in the security context
>> of some trusted component?
>>
>> Thomas
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by James Carman <ja...@carmanconsulting.com>.
Runtime.exec can be prevented though
On Sun, Nov 8, 2015 at 2:31 PM Thomas Neidhart <th...@gmail.com>
wrote:
> On 11/08/2015 08:20 PM, James Carman wrote:
> > I think this entire thing can be prevented with a security manager and a
> > proper policy in place. Nobody does that, though
>
> You cannot prevent the use of reflection for public methods via a
> SecurityManager.
>
> If you then look at the different provided payloads you can see that an
> attacker can inject arbitrary bytecode that is being loaded.
>
> How would you prevent that such code is able to do anything harmful,
> especially considering that it is being executed in the security context
> of some trusted component?
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by Thomas Neidhart <th...@gmail.com>.
On 11/08/2015 08:20 PM, James Carman wrote:
> I think this entire thing can be prevented with a security manager and a
> proper policy in place. Nobody does that, though
You cannot prevent the use of reflection for public methods via a
SecurityManager.
If you then look at the different provided payloads you can see that an
attacker can inject arbitrary bytecode that is being loaded.
How would you prevent that such code is able to do anything harmful,
especially considering that it is being executed in the security context
of some trusted component?
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
Posted by Mark Struberg <st...@yahoo.de>.
SecurityManager is an ancient part and heavily slows down the JVM. That’s the reason why almost nobody is using it.
LieGrue,
strub
> Am 08.11.2015 um 20:20 schrieb James Carman <ja...@carmanconsulting.com>:
>
> I think this entire thing can be prevented with a security manager and a
> proper policy in place. Nobody does that, though
>
> On Sun, Nov 8, 2015 at 2:10 PM Thomas Neidhart <th...@gmail.com>
> wrote:
>
>> On 11/08/2015 07:51 PM, James Carman wrote:
>>> Couldn't they use the same attack vector to set a system property also? I
>>> do believe that would be possible
>>
>> for this you need a way to execute code via a de-serialized class.
>> Right now, the simplest way to do so is via the InvokerTransformer.
>>
>> There are surely other ways to do so, but if the only available way is
>> blocked (i.e. InvokerTransformer can not be deserialized), a remote
>> attacker cannot set a system property via this attack vector.
>>
>> btw. setting a system property can also be restricted by a SecurityManager.
>>
>> I am -1 on a programmatic interface, and for the 4.X branch I propose to
>> remove the serialization support completely.
>>
>> Thomas
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by James Carman <ja...@carmanconsulting.com>.
I think this entire thing can be prevented with a security manager and a
proper policy in place. Nobody does that, though
On Sun, Nov 8, 2015 at 2:10 PM Thomas Neidhart <th...@gmail.com>
wrote:
> On 11/08/2015 07:51 PM, James Carman wrote:
> > Couldn't they use the same attack vector to set a system property also? I
> > do believe that would be possible
>
> for this you need a way to execute code via a de-serialized class.
> Right now, the simplest way to do so is via the InvokerTransformer.
>
> There are surely other ways to do so, but if the only available way is
> blocked (i.e. InvokerTransformer can not be deserialized), a remote
> attacker cannot set a system property via this attack vector.
>
> btw. setting a system property can also be restricted by a SecurityManager.
>
> I am -1 on a programmatic interface, and for the 4.X branch I propose to
> remove the serialization support completely.
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by Thomas Neidhart <th...@gmail.com>.
On 11/08/2015 07:51 PM, James Carman wrote:
> Couldn't they use the same attack vector to set a system property also? I
> do believe that would be possible
for this you need a way to execute code via a de-serialized class.
Right now, the simplest way to do so is via the InvokerTransformer.
There are surely other ways to do so, but if the only available way is
blocked (i.e. InvokerTransformer can not be deserialized), a remote
attacker cannot set a system property via this attack vector.
btw. setting a system property can also be restricted by a SecurityManager.
I am -1 on a programmatic interface, and for the 4.X branch I propose to
remove the serialization support completely.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by James Carman <ja...@carmanconsulting.com>.
Couldn't they use the same attack vector to set a system property also? I
do believe that would be possible
On Sun, Nov 8, 2015 at 1:46 PM Emmanuel Bourg <eb...@apache.org> wrote:
> Le 08/11/2015 15:12, Thomas Neidhart a écrit :
>
> > with the default being: do not de-serialize InvokerTransformer?
> > Then I would be ok going that route.
>
> I like the idea too. I have a question though: do we use a common
> property enabling unsafe deserialization for all commons components, or
> do we use a property per component or even per class?
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 08/11/2015 15:12, Thomas Neidhart a écrit :
> with the default being: do not de-serialize InvokerTransformer?
> Then I would be ok going that route.
I like the idea too. I have a question though: do we use a common
property enabling unsafe deserialization for all commons components, or
do we use a property per component or even per class?
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by Thomas Neidhart <th...@gmail.com>.
On 11/08/2015 01:32 PM, Mark Thomas wrote:
> On 08/11/2015 10:18, Thomas Neidhart wrote:
>> On 11/07/2015 11:19 AM, Mark Thomas wrote:
>>> On 07/11/2015 10:13, Thomas Neidhart wrote:
>>>> On 11/07/2015 04:25 AM, Bernd Eckenfels wrote:
>>>>> Hello,
>>>>>
>>>>> I tried to raise that concern in the message already, but it is probably
>>>>> worth repeating it explicitly: this is not a real bug
>>>>> in the Commons-Collection class, and it might not be worse fixing it, as
>>>>> there are possibly tons of other vectors. This was also addressed by the
>>>>> original authors in the talk and even here on Twitter:
>>>>>
>>>>> https://twitter.com/gebl/status/662754611304996866
>>>>>
>>>>> however, as the "foxglove" article shows, people still point at the
>>>>> apache project, and after all it is good pratice to reduce footprints
>>>>> and attack surfaces.
>>>>
>>>> it is clear that the InvokerTransformer by itself does not have a bug,
>>>> but due to the way how java serialization is applied and considering the
>>>> fact that at least collections-3.2.1 is used *a lot* it would make sense
>>>> to provide a hardened version of collections to give people a chance to
>>>> easily avoid this line of attack in their application.
>>>>
>>>> Instead of removing the class we could prevent de-serialization of it in
>>>> the hardened jar. This would not break b/c and it is very unlikely that
>>>> the InvokerTransformer is serialized in legit ways.
>>>
>>> Rather than having hardened vs unhardened JARs, it would probably be
>>> better to use a system property to enable/disable the behaviour. I don't
>>> know the code or the vulnerability well enough to know exactly where to
>>> put this switch so it prevents the attack but has minimal impact on
>>> other uses.
>>
>> my idea was to have a binary compatible drop-in replacement that does
>> not require any configuration, so that people that happen to have
>> commons-collections 3.2.1 in their classpath can replace it with a
>> hardened version.
>>
>> But I am open to other suggestions, in the end it is important to do
>> what affected users would like to have to mitigate the problem.
>
> My main concern with a hardened JAR is that, while with just this
> vulnerability, we end up with two JARs but how many JARs will we end up
> with 3 or 4 vulnerabilities down the line. Particularly when fixing a
> vulnerability means breaking functionality. I think system properties
> scale better.
with the default being: do not de-serialize InvokerTransformer?
Then I would be ok going that route.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by James Carman <ja...@carmanconsulting.com>.
The problem is that we provide them a means to invoke a method on an object.
On Sun, Nov 8, 2015 at 1:43 PM Matt Benson <gu...@gmail.com> wrote:
> I'm only tangentially following this, but if the problem is that an
> attacker can supply malicious bytecode, then wouldn't a programmatic e.g.
> property be just as easy [for an attacker] to pass in? This would need to
> be a transient property, if included, right?
>
> Matt
> On Nov 8, 2015 8:50 AM, "Jochen Wiedmann" <jo...@gmail.com>
> wrote:
>
> > Makes sense.
> >
> >
> > On Sun, Nov 8, 2015 at 3:47 PM, Gary Gregory <ga...@gmail.com>
> > wrote:
> > > I like the property option as a stopgap.
> > >
> > > Should we add a programatic option so that programmers can also control
> > > this on a per invoker basis?
> > >
> > > Gary
> > > On Nov 8, 2015 6:43 AM, "Jochen Wiedmann" <jo...@gmail.com>
> > wrote:
> > >
> > >> I like the property based approach. In particular, because we can
> > >> evaltuate that property within
> > >>
> > >> private void readObject
> > >>
> > >> Or, in other words: We can ship a jar that has the vulnerability
> > >> disabled by default (property isn't set). However, if the user
> > >> attempts to deserialize an InvokerTransformer, he or she gets a clear
> > >> and loud exception, that advices what to do (set the property). Should
> > >> be a solution that makes everyone happy in the medium term.
> > >>
> > >> Jochen
> > >>
> > >>
> > >> On Sun, Nov 8, 2015 at 3:30 PM, sebb <se...@gmail.com> wrote:
> > >> > On 8 November 2015 at 12:32, Mark Thomas <ma...@apache.org> wrote:
> > >> >> On 08/11/2015 10:18, Thomas Neidhart wrote:
> > >> >>> On 11/07/2015 11:19 AM, Mark Thomas wrote:
> > >> >>>> On 07/11/2015 10:13, Thomas Neidhart wrote:
> > >> >>>>> On 11/07/2015 04:25 AM, Bernd Eckenfels wrote:
> > >> >>>>>> Hello,
> > >> >>>>>>
> > >> >>>>>> I tried to raise that concern in the message already, but it is
> > >> probably
> > >> >>>>>> worth repeating it explicitly: this is not a real bug
> > >> >>>>>> in the Commons-Collection class, and it might not be worse
> fixing
> > >> it, as
> > >> >>>>>> there are possibly tons of other vectors. This was also
> addressed
> > >> by the
> > >> >>>>>> original authors in the talk and even here on Twitter:
> > >> >>>>>>
> > >> >>>>>> https://twitter.com/gebl/status/662754611304996866
> > >> >>>>>>
> > >> >>>>>> however, as the "foxglove" article shows, people still point at
> > the
> > >> >>>>>> apache project, and after all it is good pratice to reduce
> > >> footprints
> > >> >>>>>> and attack surfaces.
> > >> >>>>>
> > >> >>>>> it is clear that the InvokerTransformer by itself does not have
> a
> > >> bug,
> > >> >>>>> but due to the way how java serialization is applied and
> > considering
> > >> the
> > >> >>>>> fact that at least collections-3.2.1 is used *a lot* it would
> make
> > >> sense
> > >> >>>>> to provide a hardened version of collections to give people a
> > chance
> > >> to
> > >> >>>>> easily avoid this line of attack in their application.
> > >> >>>>>
> > >> >>>>> Instead of removing the class we could prevent de-serialization
> of
> > >> it in
> > >> >>>>> the hardened jar. This would not break b/c and it is very
> unlikely
> > >> that
> > >> >>>>> the InvokerTransformer is serialized in legit ways.
> > >> >>>>
> > >> >>>> Rather than having hardened vs unhardened JARs, it would probably
> > be
> > >> >>>> better to use a system property to enable/disable the behaviour.
> I
> > >> don't
> > >> >>>> know the code or the vulnerability well enough to know exactly
> > where
> > >> to
> > >> >>>> put this switch so it prevents the attack but has minimal impact
> on
> > >> >>>> other uses.
> > >> >>>
> > >> >>> my idea was to have a binary compatible drop-in replacement that
> > does
> > >> >>> not require any configuration, so that people that happen to have
> > >> >>> commons-collections 3.2.1 in their classpath can replace it with a
> > >> >>> hardened version.
> > >> >>>
> > >> >>> But I am open to other suggestions, in the end it is important to
> do
> > >> >>> what affected users would like to have to mitigate the problem.
> > >> >>
> > >> >> My main concern with a hardened JAR is that, while with just this
> > >> >> vulnerability, we end up with two JARs but how many JARs will we
> end
> > up
> > >> >> with 3 or 4 vulnerabilities down the line. Particularly when
> fixing a
> > >> >> vulnerability means breaking functionality. I think system
> properties
> > >> >> scale better.
> > >> >
> > >> > But is there a use case for partially hardened jars?
> > >> > Surely if there are additional vulnerabilities they need to be fixed
> > as
> > >> well?
> > >> >
> > >> > Using system properties simpifies things for Commons developers,
> > >> > however it makes it harder for consumers, as they have to ensure
> that
> > >> > the property is set.
> > >> > This may be hard to check if the jar is part of a large system.
> > >> >
> > >> > Though it would allow for certain vulnerabilities to be disabled by
> > >> > default (i.e.one has set a property to enable the risky code - [*])
> > >> > and others only on demand.
> > >> >
> > >> > [*] This approach is already taken by the JDK with
> > >> > sun.net.http.allowRestrictedHeaders
> > >> > See: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6996110
> > >> >
> > >> >> Mark
> > >> >>
> > >> >>
> > >> >>
> ---------------------------------------------------------------------
> > >> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >> >> For additional commands, e-mail: dev-help@commons.apache.org
> > >> >>
> > >> >
> > >> >
> ---------------------------------------------------------------------
> > >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >> > For additional commands, e-mail: dev-help@commons.apache.org
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> The next time you hear: "Don't reinvent the wheel!"
> > >>
> > >>
> > >>
> >
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > >> For additional commands, e-mail: dev-help@commons.apache.org
> > >>
> > >>
> >
> >
> >
> > --
> > The next time you hear: "Don't reinvent the wheel!"
> >
> >
> >
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by Matt Benson <gu...@gmail.com>.
I'm only tangentially following this, but if the problem is that an
attacker can supply malicious bytecode, then wouldn't a programmatic e.g.
property be just as easy [for an attacker] to pass in? This would need to
be a transient property, if included, right?
Matt
On Nov 8, 2015 8:50 AM, "Jochen Wiedmann" <jo...@gmail.com> wrote:
> Makes sense.
>
>
> On Sun, Nov 8, 2015 at 3:47 PM, Gary Gregory <ga...@gmail.com>
> wrote:
> > I like the property option as a stopgap.
> >
> > Should we add a programatic option so that programmers can also control
> > this on a per invoker basis?
> >
> > Gary
> > On Nov 8, 2015 6:43 AM, "Jochen Wiedmann" <jo...@gmail.com>
> wrote:
> >
> >> I like the property based approach. In particular, because we can
> >> evaltuate that property within
> >>
> >> private void readObject
> >>
> >> Or, in other words: We can ship a jar that has the vulnerability
> >> disabled by default (property isn't set). However, if the user
> >> attempts to deserialize an InvokerTransformer, he or she gets a clear
> >> and loud exception, that advices what to do (set the property). Should
> >> be a solution that makes everyone happy in the medium term.
> >>
> >> Jochen
> >>
> >>
> >> On Sun, Nov 8, 2015 at 3:30 PM, sebb <se...@gmail.com> wrote:
> >> > On 8 November 2015 at 12:32, Mark Thomas <ma...@apache.org> wrote:
> >> >> On 08/11/2015 10:18, Thomas Neidhart wrote:
> >> >>> On 11/07/2015 11:19 AM, Mark Thomas wrote:
> >> >>>> On 07/11/2015 10:13, Thomas Neidhart wrote:
> >> >>>>> On 11/07/2015 04:25 AM, Bernd Eckenfels wrote:
> >> >>>>>> Hello,
> >> >>>>>>
> >> >>>>>> I tried to raise that concern in the message already, but it is
> >> probably
> >> >>>>>> worth repeating it explicitly: this is not a real bug
> >> >>>>>> in the Commons-Collection class, and it might not be worse fixing
> >> it, as
> >> >>>>>> there are possibly tons of other vectors. This was also addressed
> >> by the
> >> >>>>>> original authors in the talk and even here on Twitter:
> >> >>>>>>
> >> >>>>>> https://twitter.com/gebl/status/662754611304996866
> >> >>>>>>
> >> >>>>>> however, as the "foxglove" article shows, people still point at
> the
> >> >>>>>> apache project, and after all it is good pratice to reduce
> >> footprints
> >> >>>>>> and attack surfaces.
> >> >>>>>
> >> >>>>> it is clear that the InvokerTransformer by itself does not have a
> >> bug,
> >> >>>>> but due to the way how java serialization is applied and
> considering
> >> the
> >> >>>>> fact that at least collections-3.2.1 is used *a lot* it would make
> >> sense
> >> >>>>> to provide a hardened version of collections to give people a
> chance
> >> to
> >> >>>>> easily avoid this line of attack in their application.
> >> >>>>>
> >> >>>>> Instead of removing the class we could prevent de-serialization of
> >> it in
> >> >>>>> the hardened jar. This would not break b/c and it is very unlikely
> >> that
> >> >>>>> the InvokerTransformer is serialized in legit ways.
> >> >>>>
> >> >>>> Rather than having hardened vs unhardened JARs, it would probably
> be
> >> >>>> better to use a system property to enable/disable the behaviour. I
> >> don't
> >> >>>> know the code or the vulnerability well enough to know exactly
> where
> >> to
> >> >>>> put this switch so it prevents the attack but has minimal impact on
> >> >>>> other uses.
> >> >>>
> >> >>> my idea was to have a binary compatible drop-in replacement that
> does
> >> >>> not require any configuration, so that people that happen to have
> >> >>> commons-collections 3.2.1 in their classpath can replace it with a
> >> >>> hardened version.
> >> >>>
> >> >>> But I am open to other suggestions, in the end it is important to do
> >> >>> what affected users would like to have to mitigate the problem.
> >> >>
> >> >> My main concern with a hardened JAR is that, while with just this
> >> >> vulnerability, we end up with two JARs but how many JARs will we end
> up
> >> >> with 3 or 4 vulnerabilities down the line. Particularly when fixing a
> >> >> vulnerability means breaking functionality. I think system properties
> >> >> scale better.
> >> >
> >> > But is there a use case for partially hardened jars?
> >> > Surely if there are additional vulnerabilities they need to be fixed
> as
> >> well?
> >> >
> >> > Using system properties simpifies things for Commons developers,
> >> > however it makes it harder for consumers, as they have to ensure that
> >> > the property is set.
> >> > This may be hard to check if the jar is part of a large system.
> >> >
> >> > Though it would allow for certain vulnerabilities to be disabled by
> >> > default (i.e.one has set a property to enable the risky code - [*])
> >> > and others only on demand.
> >> >
> >> > [*] This approach is already taken by the JDK with
> >> > sun.net.http.allowRestrictedHeaders
> >> > See: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6996110
> >> >
> >> >> Mark
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> >> For additional commands, e-mail: dev-help@commons.apache.org
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> > For additional commands, e-mail: dev-help@commons.apache.org
> >> >
> >>
> >>
> >>
> >> --
> >> The next time you hear: "Don't reinvent the wheel!"
> >>
> >>
> >>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
>
>
> --
> The next time you hear: "Don't reinvent the wheel!"
>
>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by Jochen Wiedmann <jo...@gmail.com>.
Makes sense.
On Sun, Nov 8, 2015 at 3:47 PM, Gary Gregory <ga...@gmail.com> wrote:
> I like the property option as a stopgap.
>
> Should we add a programatic option so that programmers can also control
> this on a per invoker basis?
>
> Gary
> On Nov 8, 2015 6:43 AM, "Jochen Wiedmann" <jo...@gmail.com> wrote:
>
>> I like the property based approach. In particular, because we can
>> evaltuate that property within
>>
>> private void readObject
>>
>> Or, in other words: We can ship a jar that has the vulnerability
>> disabled by default (property isn't set). However, if the user
>> attempts to deserialize an InvokerTransformer, he or she gets a clear
>> and loud exception, that advices what to do (set the property). Should
>> be a solution that makes everyone happy in the medium term.
>>
>> Jochen
>>
>>
>> On Sun, Nov 8, 2015 at 3:30 PM, sebb <se...@gmail.com> wrote:
>> > On 8 November 2015 at 12:32, Mark Thomas <ma...@apache.org> wrote:
>> >> On 08/11/2015 10:18, Thomas Neidhart wrote:
>> >>> On 11/07/2015 11:19 AM, Mark Thomas wrote:
>> >>>> On 07/11/2015 10:13, Thomas Neidhart wrote:
>> >>>>> On 11/07/2015 04:25 AM, Bernd Eckenfels wrote:
>> >>>>>> Hello,
>> >>>>>>
>> >>>>>> I tried to raise that concern in the message already, but it is
>> probably
>> >>>>>> worth repeating it explicitly: this is not a real bug
>> >>>>>> in the Commons-Collection class, and it might not be worse fixing
>> it, as
>> >>>>>> there are possibly tons of other vectors. This was also addressed
>> by the
>> >>>>>> original authors in the talk and even here on Twitter:
>> >>>>>>
>> >>>>>> https://twitter.com/gebl/status/662754611304996866
>> >>>>>>
>> >>>>>> however, as the "foxglove" article shows, people still point at the
>> >>>>>> apache project, and after all it is good pratice to reduce
>> footprints
>> >>>>>> and attack surfaces.
>> >>>>>
>> >>>>> it is clear that the InvokerTransformer by itself does not have a
>> bug,
>> >>>>> but due to the way how java serialization is applied and considering
>> the
>> >>>>> fact that at least collections-3.2.1 is used *a lot* it would make
>> sense
>> >>>>> to provide a hardened version of collections to give people a chance
>> to
>> >>>>> easily avoid this line of attack in their application.
>> >>>>>
>> >>>>> Instead of removing the class we could prevent de-serialization of
>> it in
>> >>>>> the hardened jar. This would not break b/c and it is very unlikely
>> that
>> >>>>> the InvokerTransformer is serialized in legit ways.
>> >>>>
>> >>>> Rather than having hardened vs unhardened JARs, it would probably be
>> >>>> better to use a system property to enable/disable the behaviour. I
>> don't
>> >>>> know the code or the vulnerability well enough to know exactly where
>> to
>> >>>> put this switch so it prevents the attack but has minimal impact on
>> >>>> other uses.
>> >>>
>> >>> my idea was to have a binary compatible drop-in replacement that does
>> >>> not require any configuration, so that people that happen to have
>> >>> commons-collections 3.2.1 in their classpath can replace it with a
>> >>> hardened version.
>> >>>
>> >>> But I am open to other suggestions, in the end it is important to do
>> >>> what affected users would like to have to mitigate the problem.
>> >>
>> >> My main concern with a hardened JAR is that, while with just this
>> >> vulnerability, we end up with two JARs but how many JARs will we end up
>> >> with 3 or 4 vulnerabilities down the line. Particularly when fixing a
>> >> vulnerability means breaking functionality. I think system properties
>> >> scale better.
>> >
>> > But is there a use case for partially hardened jars?
>> > Surely if there are additional vulnerabilities they need to be fixed as
>> well?
>> >
>> > Using system properties simpifies things for Commons developers,
>> > however it makes it harder for consumers, as they have to ensure that
>> > the property is set.
>> > This may be hard to check if the jar is part of a large system.
>> >
>> > Though it would allow for certain vulnerabilities to be disabled by
>> > default (i.e.one has set a property to enable the risky code - [*])
>> > and others only on demand.
>> >
>> > [*] This approach is already taken by the JDK with
>> > sun.net.http.allowRestrictedHeaders
>> > See: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6996110
>> >
>> >> Mark
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>>
>>
>>
>> --
>> The next time you hear: "Don't reinvent the wheel!"
>>
>>
>> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
--
The next time you hear: "Don't reinvent the wheel!"
http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by Gary Gregory <ga...@gmail.com>.
I like the property option as a stopgap.
Should we add a programatic option so that programmers can also control
this on a per invoker basis?
Gary
On Nov 8, 2015 6:43 AM, "Jochen Wiedmann" <jo...@gmail.com> wrote:
> I like the property based approach. In particular, because we can
> evaltuate that property within
>
> private void readObject
>
> Or, in other words: We can ship a jar that has the vulnerability
> disabled by default (property isn't set). However, if the user
> attempts to deserialize an InvokerTransformer, he or she gets a clear
> and loud exception, that advices what to do (set the property). Should
> be a solution that makes everyone happy in the medium term.
>
> Jochen
>
>
> On Sun, Nov 8, 2015 at 3:30 PM, sebb <se...@gmail.com> wrote:
> > On 8 November 2015 at 12:32, Mark Thomas <ma...@apache.org> wrote:
> >> On 08/11/2015 10:18, Thomas Neidhart wrote:
> >>> On 11/07/2015 11:19 AM, Mark Thomas wrote:
> >>>> On 07/11/2015 10:13, Thomas Neidhart wrote:
> >>>>> On 11/07/2015 04:25 AM, Bernd Eckenfels wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> I tried to raise that concern in the message already, but it is
> probably
> >>>>>> worth repeating it explicitly: this is not a real bug
> >>>>>> in the Commons-Collection class, and it might not be worse fixing
> it, as
> >>>>>> there are possibly tons of other vectors. This was also addressed
> by the
> >>>>>> original authors in the talk and even here on Twitter:
> >>>>>>
> >>>>>> https://twitter.com/gebl/status/662754611304996866
> >>>>>>
> >>>>>> however, as the "foxglove" article shows, people still point at the
> >>>>>> apache project, and after all it is good pratice to reduce
> footprints
> >>>>>> and attack surfaces.
> >>>>>
> >>>>> it is clear that the InvokerTransformer by itself does not have a
> bug,
> >>>>> but due to the way how java serialization is applied and considering
> the
> >>>>> fact that at least collections-3.2.1 is used *a lot* it would make
> sense
> >>>>> to provide a hardened version of collections to give people a chance
> to
> >>>>> easily avoid this line of attack in their application.
> >>>>>
> >>>>> Instead of removing the class we could prevent de-serialization of
> it in
> >>>>> the hardened jar. This would not break b/c and it is very unlikely
> that
> >>>>> the InvokerTransformer is serialized in legit ways.
> >>>>
> >>>> Rather than having hardened vs unhardened JARs, it would probably be
> >>>> better to use a system property to enable/disable the behaviour. I
> don't
> >>>> know the code or the vulnerability well enough to know exactly where
> to
> >>>> put this switch so it prevents the attack but has minimal impact on
> >>>> other uses.
> >>>
> >>> my idea was to have a binary compatible drop-in replacement that does
> >>> not require any configuration, so that people that happen to have
> >>> commons-collections 3.2.1 in their classpath can replace it with a
> >>> hardened version.
> >>>
> >>> But I am open to other suggestions, in the end it is important to do
> >>> what affected users would like to have to mitigate the problem.
> >>
> >> My main concern with a hardened JAR is that, while with just this
> >> vulnerability, we end up with two JARs but how many JARs will we end up
> >> with 3 or 4 vulnerabilities down the line. Particularly when fixing a
> >> vulnerability means breaking functionality. I think system properties
> >> scale better.
> >
> > But is there a use case for partially hardened jars?
> > Surely if there are additional vulnerabilities they need to be fixed as
> well?
> >
> > Using system properties simpifies things for Commons developers,
> > however it makes it harder for consumers, as they have to ensure that
> > the property is set.
> > This may be hard to check if the jar is part of a large system.
> >
> > Though it would allow for certain vulnerabilities to be disabled by
> > default (i.e.one has set a property to enable the risky code - [*])
> > and others only on demand.
> >
> > [*] This approach is already taken by the JDK with
> > sun.net.http.allowRestrictedHeaders
> > See: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6996110
> >
> >> Mark
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
>
> --
> The next time you hear: "Don't reinvent the wheel!"
>
>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by Jochen Wiedmann <jo...@gmail.com>.
I like the property based approach. In particular, because we can
evaltuate that property within
private void readObject
Or, in other words: We can ship a jar that has the vulnerability
disabled by default (property isn't set). However, if the user
attempts to deserialize an InvokerTransformer, he or she gets a clear
and loud exception, that advices what to do (set the property). Should
be a solution that makes everyone happy in the medium term.
Jochen
On Sun, Nov 8, 2015 at 3:30 PM, sebb <se...@gmail.com> wrote:
> On 8 November 2015 at 12:32, Mark Thomas <ma...@apache.org> wrote:
>> On 08/11/2015 10:18, Thomas Neidhart wrote:
>>> On 11/07/2015 11:19 AM, Mark Thomas wrote:
>>>> On 07/11/2015 10:13, Thomas Neidhart wrote:
>>>>> On 11/07/2015 04:25 AM, Bernd Eckenfels wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I tried to raise that concern in the message already, but it is probably
>>>>>> worth repeating it explicitly: this is not a real bug
>>>>>> in the Commons-Collection class, and it might not be worse fixing it, as
>>>>>> there are possibly tons of other vectors. This was also addressed by the
>>>>>> original authors in the talk and even here on Twitter:
>>>>>>
>>>>>> https://twitter.com/gebl/status/662754611304996866
>>>>>>
>>>>>> however, as the "foxglove" article shows, people still point at the
>>>>>> apache project, and after all it is good pratice to reduce footprints
>>>>>> and attack surfaces.
>>>>>
>>>>> it is clear that the InvokerTransformer by itself does not have a bug,
>>>>> but due to the way how java serialization is applied and considering the
>>>>> fact that at least collections-3.2.1 is used *a lot* it would make sense
>>>>> to provide a hardened version of collections to give people a chance to
>>>>> easily avoid this line of attack in their application.
>>>>>
>>>>> Instead of removing the class we could prevent de-serialization of it in
>>>>> the hardened jar. This would not break b/c and it is very unlikely that
>>>>> the InvokerTransformer is serialized in legit ways.
>>>>
>>>> Rather than having hardened vs unhardened JARs, it would probably be
>>>> better to use a system property to enable/disable the behaviour. I don't
>>>> know the code or the vulnerability well enough to know exactly where to
>>>> put this switch so it prevents the attack but has minimal impact on
>>>> other uses.
>>>
>>> my idea was to have a binary compatible drop-in replacement that does
>>> not require any configuration, so that people that happen to have
>>> commons-collections 3.2.1 in their classpath can replace it with a
>>> hardened version.
>>>
>>> But I am open to other suggestions, in the end it is important to do
>>> what affected users would like to have to mitigate the problem.
>>
>> My main concern with a hardened JAR is that, while with just this
>> vulnerability, we end up with two JARs but how many JARs will we end up
>> with 3 or 4 vulnerabilities down the line. Particularly when fixing a
>> vulnerability means breaking functionality. I think system properties
>> scale better.
>
> But is there a use case for partially hardened jars?
> Surely if there are additional vulnerabilities they need to be fixed as well?
>
> Using system properties simpifies things for Commons developers,
> however it makes it harder for consumers, as they have to ensure that
> the property is set.
> This may be hard to check if the jar is part of a large system.
>
> Though it would allow for certain vulnerabilities to be disabled by
> default (i.e.one has set a property to enable the risky code - [*])
> and others only on demand.
>
> [*] This approach is already taken by the JDK with
> sun.net.http.allowRestrictedHeaders
> See: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6996110
>
>> Mark
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
The next time you hear: "Don't reinvent the wheel!"
http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by sebb <se...@gmail.com>.
On 8 November 2015 at 12:32, Mark Thomas <ma...@apache.org> wrote:
> On 08/11/2015 10:18, Thomas Neidhart wrote:
>> On 11/07/2015 11:19 AM, Mark Thomas wrote:
>>> On 07/11/2015 10:13, Thomas Neidhart wrote:
>>>> On 11/07/2015 04:25 AM, Bernd Eckenfels wrote:
>>>>> Hello,
>>>>>
>>>>> I tried to raise that concern in the message already, but it is probably
>>>>> worth repeating it explicitly: this is not a real bug
>>>>> in the Commons-Collection class, and it might not be worse fixing it, as
>>>>> there are possibly tons of other vectors. This was also addressed by the
>>>>> original authors in the talk and even here on Twitter:
>>>>>
>>>>> https://twitter.com/gebl/status/662754611304996866
>>>>>
>>>>> however, as the "foxglove" article shows, people still point at the
>>>>> apache project, and after all it is good pratice to reduce footprints
>>>>> and attack surfaces.
>>>>
>>>> it is clear that the InvokerTransformer by itself does not have a bug,
>>>> but due to the way how java serialization is applied and considering the
>>>> fact that at least collections-3.2.1 is used *a lot* it would make sense
>>>> to provide a hardened version of collections to give people a chance to
>>>> easily avoid this line of attack in their application.
>>>>
>>>> Instead of removing the class we could prevent de-serialization of it in
>>>> the hardened jar. This would not break b/c and it is very unlikely that
>>>> the InvokerTransformer is serialized in legit ways.
>>>
>>> Rather than having hardened vs unhardened JARs, it would probably be
>>> better to use a system property to enable/disable the behaviour. I don't
>>> know the code or the vulnerability well enough to know exactly where to
>>> put this switch so it prevents the attack but has minimal impact on
>>> other uses.
>>
>> my idea was to have a binary compatible drop-in replacement that does
>> not require any configuration, so that people that happen to have
>> commons-collections 3.2.1 in their classpath can replace it with a
>> hardened version.
>>
>> But I am open to other suggestions, in the end it is important to do
>> what affected users would like to have to mitigate the problem.
>
> My main concern with a hardened JAR is that, while with just this
> vulnerability, we end up with two JARs but how many JARs will we end up
> with 3 or 4 vulnerabilities down the line. Particularly when fixing a
> vulnerability means breaking functionality. I think system properties
> scale better.
But is there a use case for partially hardened jars?
Surely if there are additional vulnerabilities they need to be fixed as well?
Using system properties simpifies things for Commons developers,
however it makes it harder for consumers, as they have to ensure that
the property is set.
This may be hard to check if the jar is part of a large system.
Though it would allow for certain vulnerabilities to be disabled by
default (i.e.one has set a property to enable the risky code - [*])
and others only on demand.
[*] This approach is already taken by the JDK with
sun.net.http.allowRestrictedHeaders
See: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6996110
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by Mark Thomas <ma...@apache.org>.
On 08/11/2015 10:18, Thomas Neidhart wrote:
> On 11/07/2015 11:19 AM, Mark Thomas wrote:
>> On 07/11/2015 10:13, Thomas Neidhart wrote:
>>> On 11/07/2015 04:25 AM, Bernd Eckenfels wrote:
>>>> Hello,
>>>>
>>>> I tried to raise that concern in the message already, but it is probably
>>>> worth repeating it explicitly: this is not a real bug
>>>> in the Commons-Collection class, and it might not be worse fixing it, as
>>>> there are possibly tons of other vectors. This was also addressed by the
>>>> original authors in the talk and even here on Twitter:
>>>>
>>>> https://twitter.com/gebl/status/662754611304996866
>>>>
>>>> however, as the "foxglove" article shows, people still point at the
>>>> apache project, and after all it is good pratice to reduce footprints
>>>> and attack surfaces.
>>>
>>> it is clear that the InvokerTransformer by itself does not have a bug,
>>> but due to the way how java serialization is applied and considering the
>>> fact that at least collections-3.2.1 is used *a lot* it would make sense
>>> to provide a hardened version of collections to give people a chance to
>>> easily avoid this line of attack in their application.
>>>
>>> Instead of removing the class we could prevent de-serialization of it in
>>> the hardened jar. This would not break b/c and it is very unlikely that
>>> the InvokerTransformer is serialized in legit ways.
>>
>> Rather than having hardened vs unhardened JARs, it would probably be
>> better to use a system property to enable/disable the behaviour. I don't
>> know the code or the vulnerability well enough to know exactly where to
>> put this switch so it prevents the attack but has minimal impact on
>> other uses.
>
> my idea was to have a binary compatible drop-in replacement that does
> not require any configuration, so that people that happen to have
> commons-collections 3.2.1 in their classpath can replace it with a
> hardened version.
>
> But I am open to other suggestions, in the end it is important to do
> what affected users would like to have to mitigate the problem.
My main concern with a hardened JAR is that, while with just this
vulnerability, we end up with two JARs but how many JARs will we end up
with 3 or 4 vulnerabilities down the line. Particularly when fixing a
vulnerability means breaking functionality. I think system properties
scale better.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by Thomas Neidhart <th...@gmail.com>.
On 11/07/2015 11:19 AM, Mark Thomas wrote:
> On 07/11/2015 10:13, Thomas Neidhart wrote:
>> On 11/07/2015 04:25 AM, Bernd Eckenfels wrote:
>>> Hello,
>>>
>>> I tried to raise that concern in the message already, but it is probably
>>> worth repeating it explicitly: this is not a real bug
>>> in the Commons-Collection class, and it might not be worse fixing it, as
>>> there are possibly tons of other vectors. This was also addressed by the
>>> original authors in the talk and even here on Twitter:
>>>
>>> https://twitter.com/gebl/status/662754611304996866
>>>
>>> however, as the "foxglove" article shows, people still point at the
>>> apache project, and after all it is good pratice to reduce footprints
>>> and attack surfaces.
>>
>> it is clear that the InvokerTransformer by itself does not have a bug,
>> but due to the way how java serialization is applied and considering the
>> fact that at least collections-3.2.1 is used *a lot* it would make sense
>> to provide a hardened version of collections to give people a chance to
>> easily avoid this line of attack in their application.
>>
>> Instead of removing the class we could prevent de-serialization of it in
>> the hardened jar. This would not break b/c and it is very unlikely that
>> the InvokerTransformer is serialized in legit ways.
>
> Rather than having hardened vs unhardened JARs, it would probably be
> better to use a system property to enable/disable the behaviour. I don't
> know the code or the vulnerability well enough to know exactly where to
> put this switch so it prevents the attack but has minimal impact on
> other uses.
my idea was to have a binary compatible drop-in replacement that does
not require any configuration, so that people that happen to have
commons-collections 3.2.1 in their classpath can replace it with a
hardened version.
But I am open to other suggestions, in the end it is important to do
what affected users would like to have to mitigate the problem.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by Mark Thomas <ma...@apache.org>.
On 07/11/2015 10:13, Thomas Neidhart wrote:
> On 11/07/2015 04:25 AM, Bernd Eckenfels wrote:
>> Hello,
>>
>> I tried to raise that concern in the message already, but it is probably
>> worth repeating it explicitly: this is not a real bug
>> in the Commons-Collection class, and it might not be worse fixing it, as
>> there are possibly tons of other vectors. This was also addressed by the
>> original authors in the talk and even here on Twitter:
>>
>> https://twitter.com/gebl/status/662754611304996866
>>
>> however, as the "foxglove" article shows, people still point at the
>> apache project, and after all it is good pratice to reduce footprints
>> and attack surfaces.
>
> it is clear that the InvokerTransformer by itself does not have a bug,
> but due to the way how java serialization is applied and considering the
> fact that at least collections-3.2.1 is used *a lot* it would make sense
> to provide a hardened version of collections to give people a chance to
> easily avoid this line of attack in their application.
>
> Instead of removing the class we could prevent de-serialization of it in
> the hardened jar. This would not break b/c and it is very unlikely that
> the InvokerTransformer is serialized in legit ways.
Rather than having hardened vs unhardened JARs, it would probably be
better to use a system property to enable/disable the behaviour. I don't
know the code or the vulnerability well enough to know exactly where to
put this switch so it prevents the attack but has minimal impact on
other uses.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java
object serialisation exploits
Posted by ec...@zusammenkunft.net.
>> Both sample payloads have "gadget chains" which do start (readObject())
>> in JCL classes and then use pretty generic interfaces like Annotations
>> or Comparators, so there is really no link between the types and the
>> specific weakness.
> I did not see JCL (commons logging?) used in the gadget chains.
JCL = Jaca Class Library (in this case ,)
--
http://bernd.eckenfels.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by Thomas Neidhart <th...@gmail.com>.
On 11/07/2015 04:25 AM, Bernd Eckenfels wrote:
> Hello,
>
> I tried to raise that concern in the message already, but it is probably
> worth repeating it explicitly: this is not a real bug
> in the Commons-Collection class, and it might not be worse fixing it, as
> there are possibly tons of other vectors. This was also addressed by the
> original authors in the talk and even here on Twitter:
>
> https://twitter.com/gebl/status/662754611304996866
>
> however, as the "foxglove" article shows, people still point at the
> apache project, and after all it is good pratice to reduce footprints
> and attack surfaces.
it is clear that the InvokerTransformer by itself does not have a bug,
but due to the way how java serialization is applied and considering the
fact that at least collections-3.2.1 is used *a lot* it would make sense
to provide a hardened version of collections to give people a chance to
easily avoid this line of attack in their application.
Instead of removing the class we could prevent de-serialization of it in
the hardened jar. This would not break b/c and it is very unlikely that
the InvokerTransformer is serialized in legit ways.
Other ways to fix this issue seem to be quite complex, i.e. change the
way serialization is performed (use whitelisting, ...), and will most
likely not be executed in a timely manner. I wonder if some people
already ship a collections version with this class being
removed/manipulated, or use a runtime weaving technique to remove the
serialization support from it?
Setting up a reasonable security policy for this line of attack also
seems to be futile as it would have to be so restrictive that most
applications probably wont work anymore.
> So it seems to be a good idea to discuss some hardening. Unfortunatelly
> having a hardened distribution with only this one class removed might
> be a bit overkill. Are there other candidates to be left out in such a
> more specific distribution? Maybe everything proxy/reflection related?
I checked the codebase, and there are other Invoker* type classes but
they all use internally the InvokerTransformer.
> Both sample payloads have "gadget chains" which do start (readObject())
> in JCL classes and then use pretty generic interfaces like Annotations
> or Comparators, so there is really no link between the types and the
> specific weakness.
I did not see JCL (commons logging?) used in the gadget chains.
btw. the technique using the TransformerImpl from xalan (which is part
of the oracle/openjdk jre) is really scary as it allows an attacker to
inject arbitrary bytecode.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java
object serialisation exploits
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Hello,
I tried to raise that concern in the message already, but it is probably
worth repeating it explicitly: this is not a real bug
in the Commons-Collection class, and it might not be worse fixing it, as
there are possibly tons of other vectors. This was also addressed by the
original authors in the talk and even here on Twitter:
https://twitter.com/gebl/status/662754611304996866
however, as the "foxglove" article shows, people still point at the
apache project, and after all it is good pratice to reduce footprints
and attack surfaces.
So it seems to be a good idea to discuss some hardening. Unfortunatelly
having a hardened distribution with only this one class removed might
be a bit overkill. Are there other candidates to be left out in such a
more specific distribution? Maybe everything proxy/reflection related?
Both sample payloads have "gadget chains" which do start (readObject())
in JCL classes and then use pretty generic interfaces like Annotations
or Comparators, so there is really no link between the types and the
specific weakness.
Greetings
Bernd
Am Sat, 7 Nov 2015 00:56:00 +0100
schrieb Thomas Neidhart <th...@gmail.com>:
> On 11/06/2015 10:25 PM, Bernd Eckenfels wrote:
> > ello,
> >
> > I came across this article:
> >
> > http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
> >
> > It describes attacks against common Java applications with
> > pre-authentication requests using malicious Java Object
> > serialisation. It builds upon the work of Gabriel Lawrence (@gebl)
> > and Chris Frohoff (@frohoff) (presented on January 28th, 2015,
> > “Marshalling Pickles” given at AppSecCali)
> >
> > http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles
> >
> > The ysoserial tool has some sample payloads, two use
> > commons-collection oac.collections.functors.InvokerTransformer. *
> >
> > https://github.com/frohoff/ysoserial/tree/master/src/main/java/ysoserial/payloads
> >
> > The class itself is rather handy to break out of the readObject()
> > chains to execute arbitrary methods.
> >
> > I do'nt recall any discussion here about this
> > class. Is this currently handled/reported? Of course the more
> > general problem is using serialisation with untusted peers, and if
> > commons-collection fixes this, there might still be other vectors,
> > but still I think it would be good to do something against that
> > "bad press"?
>
> I was not aware of this yet, thanks for the pointers.
>
> If we would remove the problematic classes and release a new
> collections version (for the 3.x or 4.x branch) we would break source
> and binary compatibility.
>
> It might be acceptable/doable to release a collections version with an
> additional maven classifier (e.g. -hardened) that removes the relevant
> classes and explain the compatibility issues in detail in the release
> notes. What do others think about something like that?
...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by Thomas Neidhart <th...@gmail.com>.
On 11/07/2015 12:56 AM, Thomas Neidhart wrote:
> On 11/06/2015 10:25 PM, Bernd Eckenfels wrote:
>> ello,
>>
>> I came across this article:
>>
>> http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
>>
>> It describes attacks against common Java applications with
>> pre-authentication requests using malicious Java Object serialisation.
>> It builds upon the work of Gabriel Lawrence (@gebl) and Chris Frohoff
>> (@frohoff) (presented on January 28th, 2015, “Marshalling Pickles”
>> given at AppSecCali)
>>
>> http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles
>>
>> The ysoserial tool has some sample payloads, two use
>> commons-collection oac.collections.functors.InvokerTransformer. *
>>
>> https://github.com/frohoff/ysoserial/tree/master/src/main/java/ysoserial/payloads
>>
>> The class itself is rather handy to break out of the readObject()
>> chains to execute arbitrary methods.
>>
>> I do'nt recall any discussion here about this
>> class. Is this currently handled/reported? Of course the more general
>> problem is using serialisation with untusted peers, and if
>> commons-collection fixes this, there might still be other vectors, but
>> still I think it would be good to do something against that "bad press"?
>
> I was not aware of this yet, thanks for the pointers.
>
> If we would remove the problematic classes and release a new collections
> version (for the 3.x or 4.x branch) we would break source and binary
> compatibility.
>
> It might be acceptable/doable to release a collections version with an
> additional maven classifier (e.g. -hardened) that removes the relevant
> classes and explain the compatibility issues in detail in the release
> notes. What do others think about something like that?
>
> btw. with Java 8 you can do similar things by using serialized method
> references. I did create a very simple example to illustrate the issue:
>
> public class MyTest {
>
> public static void main(String[] args) throws Exception {
> final SAM1 m1 = (SAM1 & Serializable) Runtime::getRuntime;
> final SAM2 m2 = (SAM2 & Serializable) Runtime::exec;
>
> Transformer t1 = (Transformer & Serializable) (input) -> m1.action();
> Transformer t2 = (Transformer & Serializable) (input) -> {
> try {
> Process p = m2.action((Runtime) input, "ls");
>
> String line;
> StringBuilder output = new StringBuilder();
> BufferedReader reader = new BufferedReader(new
> InputStreamReader(p.getInputStream()));
> while ((line = reader.readLine()) != null) {
> output.append(line);
> output.append("\n");
> }
> reader.close();
> return output.toString();
> } catch (IOException e) {
> return null;
> }
> };
>
> ChainedTransformer chain = new ChainedTransformer(t1, t2);
> TransformedList list = TransformedList.transformedList(new
> ArrayList(), chain);
>
> FileOutputStream fos = new FileOutputStream("test.ser");
> ObjectOutputStream os = new ObjectOutputStream(fos);
> os.writeObject(list);
> os.close();
>
> FileInputStream fis = new FileInputStream("test.ser");
> ObjectInputStream ois = new ObjectInputStream(fis);
>
> List l2 = (List)ois.readObject();
>
> l2.add(1);
>
> //Print the result
> System.out.println(l2);
> ois.close();
> }
>
> interface SAM1 {
> Runtime action();
> }
>
> interface SAM2 {
> Process action(Runtime r, String s) throws IOException;
> }
>
I was a bit too fast with this. This example will only work if the
remote site has the same code otherwise the lambda functions can not be
de-serialized.
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object
serialisation exploits
Posted by Thomas Neidhart <th...@gmail.com>.
On 11/06/2015 10:25 PM, Bernd Eckenfels wrote:
> ello,
>
> I came across this article:
>
> http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
>
> It describes attacks against common Java applications with
> pre-authentication requests using malicious Java Object serialisation.
> It builds upon the work of Gabriel Lawrence (@gebl) and Chris Frohoff
> (@frohoff) (presented on January 28th, 2015, “Marshalling Pickles”
> given at AppSecCali)
>
> http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles
>
> The ysoserial tool has some sample payloads, two use
> commons-collection oac.collections.functors.InvokerTransformer. *
>
> https://github.com/frohoff/ysoserial/tree/master/src/main/java/ysoserial/payloads
>
> The class itself is rather handy to break out of the readObject()
> chains to execute arbitrary methods.
>
> I do'nt recall any discussion here about this
> class. Is this currently handled/reported? Of course the more general
> problem is using serialisation with untusted peers, and if
> commons-collection fixes this, there might still be other vectors, but
> still I think it would be good to do something against that "bad press"?
I was not aware of this yet, thanks for the pointers.
If we would remove the problematic classes and release a new collections
version (for the 3.x or 4.x branch) we would break source and binary
compatibility.
It might be acceptable/doable to release a collections version with an
additional maven classifier (e.g. -hardened) that removes the relevant
classes and explain the compatibility issues in detail in the release
notes. What do others think about something like that?
btw. with Java 8 you can do similar things by using serialized method
references. I did create a very simple example to illustrate the issue:
public class MyTest {
public static void main(String[] args) throws Exception {
final SAM1 m1 = (SAM1 & Serializable) Runtime::getRuntime;
final SAM2 m2 = (SAM2 & Serializable) Runtime::exec;
Transformer t1 = (Transformer & Serializable) (input) -> m1.action();
Transformer t2 = (Transformer & Serializable) (input) -> {
try {
Process p = m2.action((Runtime) input, "ls");
String line;
StringBuilder output = new StringBuilder();
BufferedReader reader = new BufferedReader(new
InputStreamReader(p.getInputStream()));
while ((line = reader.readLine()) != null) {
output.append(line);
output.append("\n");
}
reader.close();
return output.toString();
} catch (IOException e) {
return null;
}
};
ChainedTransformer chain = new ChainedTransformer(t1, t2);
TransformedList list = TransformedList.transformedList(new
ArrayList(), chain);
FileOutputStream fos = new FileOutputStream("test.ser");
ObjectOutputStream os = new ObjectOutputStream(fos);
os.writeObject(list);
os.close();
FileInputStream fis = new FileInputStream("test.ser");
ObjectInputStream ois = new ObjectInputStream(fis);
List l2 = (List)ois.readObject();
l2.add(1);
//Print the result
System.out.println(l2);
ois.close();
}
interface SAM1 {
Runtime action();
}
interface SAM2 {
Process action(Runtime r, String s) throws IOException;
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org