Re-sending the references since the formatting and links seemed to have gotten a bit messed up.
Further references: Beanutils gadget chain: https://gist.github.com/frohoff/9eb8811761ff989b3ac0 AppSecCali Marshalling Pickles Talk: http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles ysoserial payload generator: https://github.com/frohoff/ysoserial JRE 7u21 Advisory: https://gist.github.com/frohoff/24af7913611f8406eaf3 Apache Commons statement: https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread On Monday, February 22, 2016 1:59 PM, Chris Frohoff <froh...@yahoo.com> wrote: All, I already sent something similar to the private security list (secur...@apache.org) earlier this month and it was suggested that I post it to the dev list for discussion. There is a Java deserialization "gadget" in the commons-beanutils library that can be used along with others in the JRE to achieve code/command execution in applications deserializing untrusted data, similar to the ones recently discussed in the commons-collections library. Specifically, an instance of the commons-beanutils class `BeanComparator` can be used during deserialization of a containing collection to invoke the `getOutputProperties()` getter method on a TemplatesImpl instance, defining arbitrary and potentially malicious classes (very similar to the CommonsCollections2 gadget chain). A proof-of-concept payload generator is available in this gist: https://gist.github.com/ frohoff/9eb8811761ff989b3ac0 To be clear, I don't believe that this should necessarily be a concern of library developers and that protections should really be implemented by code doing the unsafe deserialization. This is in line with the previous Apache Commons statement regarding the vunlerabilities discourse from last year (https://blogs.apache.org/ foundation/entry/apache_ commons_statement_to_ widespread). That being said, some people seem to disagree, and there seems to be a desire for libraries to provide mitigations, so a new release with a patch may be warranted. I discovered this last year, but for better or worse, wanted to wait until I could publicly disclose a similar issue with only JRE (<7u21) classes (https://gist.github.com/ frohoff/24af7913611f8406eaf3) to further emphasize that this is a more pervasive problem that should be addressed in a more robust way than playing "whack-a-mole" with gadget classes (seehttps://gist.github.com/ frohoff/24af7913611f8406eaf3# mitigation for recommendations). I'm happy answer questions, review code/patches, and otherwise help in any way I can. Regards, -Chris Frohoff Further references: Beanutils gadget chain: https://gist.github. com/frohoff/ 9eb8811761ff989b3ac0 AppSecCali Marshalling Pickles Talk: http://www.slideshare.net/ frohoff1/appseccali-2015- marshalling-pickles ysoserial payload generator: https://github.com/ frohoff/ysoserial JRE 7u21 Advisory: https://gist.github.com/ frohoff/24af7913611f8406eaf3 Apache Commons statement: https://blogs. apache.org/foundation/entry/ apache_commons_statement_to_ widespread --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
