commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Neidhart (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer
Date Tue, 10 Nov 2015 10:01:11 GMT

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

Mime
View raw message