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