[jira] [Comment Edited] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer
[
https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046623#comment-15046623
]
Joerg Schaible edited comment on COLLECTIONS-580 at 12/8/15 11:16 AM:
--
THIS IS NOT A HELP FORUM! If you have questions, go ask on the user's list!
(Note, this was a reply to a comment that have been deleted afterwards by its
original author).
was (Author: joehni):
THIS IS NOT A HELP FORUM! If you have questions, go ask on the user's list!
> 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
> Fix For: 3.2.2, 4.1
>
> 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)
[jira] [Comment Edited] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer
[
https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15046623#comment-15046623
]
Joerg Schaible edited comment on COLLECTIONS-580 at 12/8/15 11:16 AM:
--
THIS IS NOT A HELP FORUM! If you have questions, go ask on the user's list!
(Note, this was a reply to a comment that has been deleted afterwards by its
original author).
was (Author: joehni):
THIS IS NOT A HELP FORUM! If you have questions, go ask on the user's list!
(Note, this was a reply to a comment that have been deleted afterwards by its
original author).
> 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
> Fix For: 3.2.2, 4.1
>
> 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)
[jira] [Comment Edited] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer
[
https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003932#comment-15003932
]
Karsten Klein edited comment on COLLECTIONS-580 at 11/13/15 12:37 PM:
--
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. Here
I would also suggest to remove the complete Serialization feature.
was (Author: karsten.kl...@gmail.com):
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)
[jira] [Comment Edited] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer
[
https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003912#comment-15003912
]
Karsten Klein edited comment on COLLECTIONS-580 at 11/13/15 12:20 PM:
--
We (not having seen the attached patch before) have come up with the following
solution:
{code}
/**
* Transforms the input to result by invoking a method on the input.
*
* @param input the input object to transform
* @return the transformed result, null if null input
*/
public Object transform(Object input) {
if (input == null) {
return null;
}
if (deserialized) {
throw new IllegalStateException("Transformation on deserialized
object not supported. "
+ "Using this function may indicate an attempted SECURITY
BREACH.");
}
try {
Class cls = input.getClass();
Method method = cls.getMethod(iMethodName, iParamTypes);
return method.invoke(input, iArgs);
} catch (NoSuchMethodException ex) {
throw new FunctorException("InvokerTransformer: The method '" +
iMethodName + "' on '" + input.getClass() + "' does not exist");
} catch (IllegalAccessException ex) {
throw new FunctorException("InvokerTransformer: The method '" +
iMethodName + "' on '" + input.getClass() + "' cannot be accessed");
} catch (InvocationTargetException ex) {
throw new FunctorException("InvokerTransformer: The method '" +
iMethodName + "' on '" + input.getClass() + "' threw an exception", ex);
}
}
private transient boolean deserialized = false;
private void readObject(ObjectInputStream in) throws IOException,
ClassNotFoundException {
in.defaultReadObject();
deserialized = true;
}
{code}
This approach is a little more 'compatible' and less invasive. It will only
fail if transform is invoked on a deserialized object. In particular it does
not fail at deserialization time. Only when the transform method is invoked.
This may reduce the effects of the change.
was (Author: karsten.kl...@gmail.com):
We (not having seen the attached patch before) have come up with the following
solution:
{code}
/**
* Transforms the input to result by invoking a method on the input.
*
* @param input the input object to transform
* @return the transformed result, null if null input
*/
public Object transform(Object input) {
if (input == null) {
return null;
}
if (deserialized) {
throw new IllegalStateException("Transformation on deserialized
object not supported. "
+ "Using this function may indicate an attempted SECURITY
BREACH.");
}
try {
Class cls = input.getClass();
Method method = cls.getMethod(iMethodName, iParamTypes);
return method.invoke(input, iArgs);
} catch (NoSuchMethodException ex) {
throw new FunctorException("InvokerTransformer: The method '" +
iMethodName + "' on '" + input.getClass() + "' does not exist");
} catch (IllegalAccessException ex) {
throw new FunctorException("InvokerTransformer: The method '" +
iMethodName + "' on '" + input.getClass() + "' cannot be accessed");
} catch (InvocationTargetException ex) {
throw new FunctorException("InvokerTransformer: The method '" +
iMethodName + "' on '" + input.getClass() + "' threw an exception", ex);
}
}
private transient boolean deserialized = false;
private void readObject(ObjectInputStream in) throws IOException,
ClassNotFoundException {
in.defaultReadObject();
deserialized = true;
}
{code}
This approach is the most non-invasive and 'compatible' approach. It will only
fail if transform is invoked on a deserialized object. In particular it does
not fail at deserialization time. Only when the transform method is invoked.
This may reduce the effects of the change.
> 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 (
[jira] [Comment Edited] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer
[
https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003912#comment-15003912
]
Karsten Klein edited comment on COLLECTIONS-580 at 11/13/15 12:19 PM:
--
We (not having seen the attached patch before) have come up with the following
solution:
{code}
/**
* Transforms the input to result by invoking a method on the input.
*
* @param input the input object to transform
* @return the transformed result, null if null input
*/
public Object transform(Object input) {
if (input == null) {
return null;
}
if (deserialized) {
throw new IllegalStateException("Transformation on deserialized
object not supported. "
+ "Using this function may indicate an attempted SECURITY
BREACH.");
}
try {
Class cls = input.getClass();
Method method = cls.getMethod(iMethodName, iParamTypes);
return method.invoke(input, iArgs);
} catch (NoSuchMethodException ex) {
throw new FunctorException("InvokerTransformer: The method '" +
iMethodName + "' on '" + input.getClass() + "' does not exist");
} catch (IllegalAccessException ex) {
throw new FunctorException("InvokerTransformer: The method '" +
iMethodName + "' on '" + input.getClass() + "' cannot be accessed");
} catch (InvocationTargetException ex) {
throw new FunctorException("InvokerTransformer: The method '" +
iMethodName + "' on '" + input.getClass() + "' threw an exception", ex);
}
}
private transient boolean deserialized = false;
private void readObject(ObjectInputStream in) throws IOException,
ClassNotFoundException {
in.defaultReadObject();
deserialized = true;
}
{code}
This approach is the most non-invasive and 'compatible' approach. It will only
fail if transform is invoked on a deserialized object. In particular it does
not fail at deserialization time. Only when the transform method is invoked.
This may reduce the effects of the change.
was (Author: karsten.kl...@gmail.com):
We (not having seen the attached patch before) have come up with the following
solution:
{code}
/**
* Transforms the input to result by invoking a method on the input.
*
* @param input the input object to transform
* @return the transformed result, null if null input
*/
public Object transform(Object input) {
if (input == null) {
return null;
}
if (deserialized) {
throw new IllegalStateException("Transformation on deserialized
object not supported. "
+ "Using this function may indicate an attempted SECURITY
BREACH.");
}
try {
Class cls = input.getClass();
Method method = cls.getMethod(iMethodName, iParamTypes);
return method.invoke(input, iArgs);
} catch (NoSuchMethodException ex) {
throw new FunctorException("InvokerTransformer: The method '" +
iMethodName + "' on '" + input.getClass() + "' does not exist");
} catch (IllegalAccessException ex) {
throw new FunctorException("InvokerTransformer: The method '" +
iMethodName + "' on '" + input.getClass() + "' cannot be accessed");
} catch (InvocationTargetException ex) {
throw new FunctorException("InvokerTransformer: The method '" +
iMethodName + "' on '" + input.getClass() + "' threw an exception", ex);
}
}
private transient boolean deserialized = false;
private void writeObject(ObjectOutputStream out) throws IOException {
out.defaultWriteObject();
}
private void readObject(ObjectInputStream in) throws IOException,
ClassNotFoundException {
in.defaultReadObject();
deserialized = true;
}
{code}
This approach is the most non-invasive and 'compatible' approach. It will only
fail if transform is invoked on a deserialized object. In particular it does
not fail at deserialization time. Only when the transform method is invoked.
This may reduce the effects of the change.
> 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
>
[jira] [Comment Edited] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer
[
https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15003912#comment-15003912
]
Karsten Klein edited comment on COLLECTIONS-580 at 11/13/15 12:16 PM:
--
We (not having seen the attached patch before) have come up with the following
solution:
{code}
/**
* Transforms the input to result by invoking a method on the input.
*
* @param input the input object to transform
* @return the transformed result, null if null input
*/
public Object transform(Object input) {
if (input == null) {
return null;
}
if (deserialized) {
throw new IllegalStateException("Transformation on deserialized
object not supported. "
+ "Using this function may indicate an attempted SECURITY
BREACH.");
}
try {
Class cls = input.getClass();
Method method = cls.getMethod(iMethodName, iParamTypes);
return method.invoke(input, iArgs);
} catch (NoSuchMethodException ex) {
throw new FunctorException("InvokerTransformer: The method '" +
iMethodName + "' on '" + input.getClass() + "' does not exist");
} catch (IllegalAccessException ex) {
throw new FunctorException("InvokerTransformer: The method '" +
iMethodName + "' on '" + input.getClass() + "' cannot be accessed");
} catch (InvocationTargetException ex) {
throw new FunctorException("InvokerTransformer: The method '" +
iMethodName + "' on '" + input.getClass() + "' threw an exception", ex);
}
}
private transient boolean deserialized = false;
private void writeObject(ObjectOutputStream out) throws IOException {
out.defaultWriteObject();
}
private void readObject(ObjectInputStream in) throws IOException,
ClassNotFoundException {
in.defaultReadObject();
deserialized = true;
}
{code}
This approach is the most non-invasive and 'compatible' approach. It will only
fail if transform is invoked on a deserialized object. In particular it does
not fail at deserialization time. Only when the transform method is invoked.
This may reduce the effects of the change.
was (Author: karsten.kl...@gmail.com):
We (not having seen the attached patch before) have come up with the following
solution:
{code}
/**
* Transforms the input to result by invoking a method on the input.
*
* @param input the input object to transform
* @return the transformed result, null if null input
*/
public Object transform(Object input) {
if (input == null) {
return null;
}
if (deserialized) {
throw new IllegalStateException("Transformation on deserialized
object not supported. "
+ "Using this function may indicate an attempted SECURITY
BREACH.");
}
try {
Class cls = input.getClass();
Method method = cls.getMethod(iMethodName, iParamTypes);
return method.invoke(input, iArgs);
} catch (NoSuchMethodException ex) {
throw new FunctorException("InvokerTransformer: The method '" +
iMethodName + "' on '" + input.getClass() + "' does not exist");
} catch (IllegalAccessException ex) {
throw new FunctorException("InvokerTransformer: The method '" +
iMethodName + "' on '" + input.getClass() + "' cannot be accessed");
} catch (InvocationTargetException ex) {
throw new FunctorException("InvokerTransformer: The method '" +
iMethodName + "' on '" + input.getClass() + "' threw an exception", ex);
}
}
private transient boolean deserialized = false;
private void writeObject(ObjectOutputStream out) throws IOException {
out.defaultWriteObject();
}
private void readObject(ObjectInputStream in) throws IOException,
ClassNotFoundException {
in.defaultReadObject();
deserialized = true;
}
{code}
This approach is the most non-invasive and 'compatible' approach. It will only
fail if transform is invoked on a deserialized object.
> 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}
[jira] [Comment Edited] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer
[
https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15000335#comment-15000335
]
Thomas Neidhart edited comment on COLLECTIONS-580 at 11/11/15 1:07 PM:
---
There are also other vulnerable classes that allow an attacker to create a
quite simple DOS attack.
A gadget like that will result in an infinite loop:
{code}
final Transformer[] transformers = new Transformer[] {
new ConstantTransformer(Runtime.class),
new ClosureTransformer(
new WhileClosure(TruePredicate.INSTANCE,
new TransformerClosure(CloneTransformer.INSTANCE), false)),
{code}
was (Author: tn):
There are also other vulnerable classes that allow an attacker to create a
quite simple DOS attack.
A gadget like that will result in an infinite loop:
{code}
final Transformer[] transformers = new Transformer[] {
new ConstantTransformer(Runtime.class),
new ClosureTransformer(
new WhileClosure(TruePredicate.INSTANCE,
new
TransformerClosure(CloneTransformer.INSTANCE), false)),
{code}
> 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)
[jira] [Comment Edited] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer
[
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)
