Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
Makes sense. On Sun, Nov 8, 2015 at 3:47 PM, Gary Gregorywrote: > 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" 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 wrote: >> > On 8 November 2015 at 12:32, 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. >> > >> > 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-unsubscr...@commons.apache.org >> >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> >> > >> > - >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@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 >> >>
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
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, sebbwrote: > On 8 November 2015 at 12:32, 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. > > 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-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
On 8 November 2015 at 12:32, Mark Thomaswrote: > 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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
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"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 wrote: > > On 8 November 2015 at 12:32, 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. > > > > 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-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
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 Bourgwrote: > 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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
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 Neidhartwrote: > 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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
If they can execute Runtime.exec then they can execute System.setProperty On Sun, Nov 8, 2015 at 2:11 PM James Carmanwrote: > System.setProperty() > > > On Sun, Nov 8, 2015 at 2:10 PM Thomas Neidhart > 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-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >>
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
System.setProperty() On Sun, Nov 8, 2015 at 2:10 PM Thomas Neidhartwrote: > 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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
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 Neidhartwrote: > 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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
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: > > 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 > 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-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
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"wrote: > Makes sense. > > > On Sun, Nov 8, 2015 at 3:47 PM, Gary Gregory > 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" > 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 wrote: > >> > On 8 November 2015 at 12:32, 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. > >> > > >> > 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 > >> >> > >> >> > >> >>
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
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 Bensonwrote: > 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" > wrote: > > > Makes sense. > > > > > > On Sun, Nov 8, 2015 at 3:47 PM, Gary Gregory > > 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" > > 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 wrote: > > >> > On 8 November 2015 at 12:32, 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. > > >> > > > >> > 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
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
Yes, I guess it should be prevented. Duh! On Sun, Nov 8, 2015 at 2:16 PM Mark Thomaswrote: > 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 > > wrote: > > > >> System.setProperty() > >> > >> > >> On Sun, Nov 8, 2015 at 2:10 PM Thomas Neidhart < > thomas.neidh...@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-unsubscr...@commons.apache.org > >>> For additional commands, e-mail: dev-h...@commons.apache.org > >>> > >>> > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
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> wrote: > >> System.setProperty() >> >> >> On Sun, Nov 8, 2015 at 2:10 PM Thomas Neidhart >> 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-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
Runtime.exec can be prevented though On Sun, Nov 8, 2015 at 2:31 PM Thomas Neidhartwrote: > 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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
How did we get to the point where someone could invoke arbitrary bytecode? On Sun, Nov 8, 2015 at 2:47 PM James Carmanwrote: > Runtime.exec can be prevented though > > On Sun, Nov 8, 2015 at 2:31 PM Thomas Neidhart > 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-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >>
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
>> 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
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: > 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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org