[ https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003932#comment-15003932 ]
Karsten Klein commented on COLLECTIONS-580: ------------------------------------------- Not sure I fully understand. The critical piece of code is always executed on a fully deserialized object. So the approach should work (or I apologize for not having understood the subject matter). However, awareness is required on how people have to deal with this finding. The lib is very wide-spread. Thus a minimum behavior change in the software stack is preferred. For newer versions (major/minor) I would agree to your fail-fast approach. > Arbitrary remote code execution with InvokerTransformer > ------------------------------------------------------- > > Key: COLLECTIONS-580 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-580 > Project: Commons Collections > Issue Type: Bug > Affects Versions: 3.0, 4.0 > Reporter: Philippe Marschall > Attachments: COLLECTIONS-580.patch > > > With {{InvokerTransformer}} serializable collections can be build that > execute arbitrary Java code. > {{sun.reflect.annotation.AnnotationInvocationHandler#readObject}} invokes > {{#entrySet}} and {{#get}} on a deserialized collection. If you have an > endpoint that accepts serialized Java objects (JMX, RMI, remote EJB, ...) you > can combine the two to create arbitrary remote code execution vulnerability. > I don't know of a good fix short of removing {{InvokerTransformer}} or making > it not Serializable. Both probably break existing applications. > This is not my research, but has been discovered by other people. > https://github.com/frohoff/ysoserial > http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ -- This message was sent by Atlassian JIRA (v6.3.4#6332)