[jira] [Comment Edited] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer

["Thomas Neidhart (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14998335#comment-14998335 ] 

Thomas Neidhart edited comment on COLLECTIONS-580 at 11/10/15 10:00 AM:
------------------------------------------------------------------------

Indeed, I was thinking about that as well. The point is that within the same application it does not make sense to allow serialization when de-serialization will certainly fail.
This will allow people to spot regressions earlier when using the updated jar with serialization disabled.

Furthermore, as mentioned by Chris Frohoff on the mailinglist, the following classes might be unsecure as well:

 * InstantiateFactory
 * InstantiateTransformer
 * PrototypeFactory

I think PrototypeFactory is safe: it calls clone on an object that has been de-serialized already, but for the other 2 I am not sure. Basically they allow an attacker to call an arbitrary public constructor of any class in the application's classpath. There might be a possible attack vector for it, although none is known atm.

If we add the same fix there as well, I would also suggest to change the property to enable the serialization to that: "org.apache.commons.collections.enableUnsafeSerialization"


was (Author: tn):
Indeed, I was thinking about that as well. The point is that within the same application it does not make sense to allow serialization when de-serialization will certainly fail.
This will allow people to spot regressions earlier when using the updated jar with serialization disabled.

Furthermore, as mentioned by Chris Frohoff on the mailinglist, the following class might be unsecure as well:

 * InstantiateFactory
 * InstantiateTransformer
 * PrototypeFactory

I think PrototypeFactory is safe: it calls clone on an object that has been de-serialized already, but for the other 2 I am not sure. Basically they allow an attacker to call an arbitrary public constructor of any class in the application's classpath. There might be a possible attack vector for it, although none is known atm.

If we add the same fix there as well, I would also suggest to change the property to enable the serialization to that: "org.apache.commons.collections.enableUnsafeSerialization"

> 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)