[jira] [Commented] (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=15003912#comment-15003912
]
Karsten Klein commented on COLLECTIONS-580:
---
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}} 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=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}} on a
[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=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
> {{#entrySet}}
[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=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 (JMX, RMI, remote
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15004571#comment-15004571 ] Adrian Crum commented on IO-487: Gary - right now I think we are trying to settle on an API. If there is consensus, I would be happy to write unit tests. > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15004397#comment-15004397 ] Bertrand Delacretaz commented on IO-487: Forgot to mention good contributions from [~alexander.klimetschek] on that SLING-5288 code, please also credit him if you accept the patch (alexkli at a.o). > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
Bertrand Delacretaz created IO-487: -- Summary: SafeObjectInputStream contribution - restrict which classes can be deserialized Key: IO-487 URL: https://issues.apache.org/jira/browse/IO-487 Project: Commons IO Issue Type: Improvement Components: Utilities Affects Versions: 2.4 Reporter: Bertrand Delacretaz Priority: Minor Fix For: 2.5 As discussed on the commons dev list I'd like to contribute my SLING-5288 code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15004566#comment-15004566 ] Gary Gregory commented on IO-487: - Is someone wiling to look at code coverage reports with Jacoco and/or Cobertura to make sure as much of this new code is tested? > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated IO-487: --- Attachment: IO-487.patch > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Crum updated IO-487: --- Attachment: IO-487.patch Improved patch attached. Added missing @Overrides, added missing JavaDocs, added more ClassAcceptor implementations, added thread safety. > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15004583#comment-15004583 ] Gary Gregory commented on IO-487: - Ah, OK, thank you for the update. Since are still kibitzing, then I'd like to open the class name up for debate. To me "SafeObjectInputStream" leads me to ask "safe from what?" and "How safe is it really?" Perhaps a name focused on the "doing" rather than the "intent" would be better. Maybe "AcceptorObjectInputStream", "CheckedObjectInputStream", "CheckingObjectInputStream", "ValidatingObjectInputStream". None of these are great but so far I like "ValidatingObjectInputStream". > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15004415#comment-15004415 ] Adrian Crum commented on IO-487: Some suggestions: 1. Use UnsupportedOperationException instead of custom exception class. 2. Maybe use a package whitelist/blacklist instead of regular expressions (regexes seem like overkill to me). > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated IO-487: --- Attachment: IO-487.patch Here's an updated patch that uses UnsupportedOperationException, good idea. A package-based ClassAcceptor sounds like a good idea, don't have time to write this right now. I think RegexpClassAcceptor can be useful for code with a suboptimal package organization, but that could also be made optional and not included in the library, I don't know how much you want to minimize the size of commons-io. > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487.patch, IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15004563#comment-15004563 ] Bertrand Delacretaz commented on IO-487: You are welcome! > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated IO-487: --- Attachment: IO-487.patch Another update...just a comment change. > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487.patch, IO-487.patch, IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15004453#comment-15004453 ] Adrian Crum commented on IO-487: If you don't mind, I would like to make a few improvements to your patch. > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487.patch, IO-487.patch, IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15004657#comment-15004657 ] Adrian Crum commented on IO-487: Agreed. > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15004788#comment-15004788 ] Adrian Crum commented on IO-487: I just noticed my patch utility is creating duplicates within the patch. Let me know if you have any problems applying the patch and I will fix it. > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch, > IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (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=15004712#comment-15004712
]
Thomas Neidhart commented on COLLECTIONS-580:
-
The new MultiValuedMap in collections4 uses internally an InstantiateFactory
which is serialized. Need to find a better solution for this before we can
resolve the issue.
> 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] [Commented] (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=15004640#comment-15004640
]
Thomas Neidhart commented on COLLECTIONS-580:
-
Committed in r1714262 for collections4: unsafe classes do not implement the
Serializable interface anymore.
> 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] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15004750#comment-15004750 ] Christopher Schultz commented on IO-487: I'm no expert in "commons land", but would this class be better-placed into commons-lang? I can see reasonable arguments for either commons-lang or commons-io. > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15004777#comment-15004777 ] Gary Gregory commented on IO-487: - This is clearly an IO class. > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15004623#comment-15004623 ] Christopher Schultz commented on IO-487: RegexpClassAcceptor could be simpler by reducing the whitelists and blacklists to a single Pattern for each: anyone can use | in a regular expression to support many patterns. > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Crum updated IO-487: --- Attachment: IO-487.patch Updated patch that includes the suggestions made so far. I think the latest API is flexible and easy to use. > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch, > IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15004870#comment-15004870 ] Bertrand Delacretaz commented on IO-487: RestrictedObjectInputStream? > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch, > IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15004869#comment-15004869 ] Bertrand Delacretaz commented on IO-487: RestrictedObjectInputStream? > SafeObjectInputStream contribution - restrict which classes can be > deserialized > --- > > Key: IO-487 > URL: https://issues.apache.org/jira/browse/IO-487 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.4 >Reporter: Bertrand Delacretaz >Priority: Minor > Labels: patch > Fix For: 2.5 > > Attachments: IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch, > IO-487.patch > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SANDBOX-501) Add configurable type conversion support
[ https://issues.apache.org/jira/browse/SANDBOX-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15005133#comment-15005133 ] Matthew P Mann commented on SANDBOX-501: Some more tinkering today. Attaching a new patch. > Add configurable type conversion support > > > Key: SANDBOX-501 > URL: https://issues.apache.org/jira/browse/SANDBOX-501 > Project: Commons Sandbox > Issue Type: New Feature > Components: BeanUtils2 >Reporter: Benedikt Ritter > Attachments: commons-beanutils2.java8.patch > > > BeanUtils1 supports automatic type conversion when setting properties. This > should be added to BeanUtils2. > A problem of the implementation of BeanUtils1 is, that the registry of > converts is cached in the BeanUtils class. BeanUtils2 should provide an API > for creating new instances of the o.a.c.beanutils2.BeanUtils with a > customized typ conversion registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SANDBOX-501) Add configurable type conversion support
[ https://issues.apache.org/jira/browse/SANDBOX-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15005133#comment-15005133 ] Matthew P Mann edited comment on SANDBOX-501 at 11/14/15 3:34 AM: -- Some more tinkering today. Attaching a new patch. was (Author: mattmann): Some more tinkering today. Attaching a new patch. > Add configurable type conversion support > > > Key: SANDBOX-501 > URL: https://issues.apache.org/jira/browse/SANDBOX-501 > Project: Commons Sandbox > Issue Type: New Feature > Components: BeanUtils2 >Reporter: Benedikt Ritter > Attachments: commons-beanutils2.2015-11-13.patch, > commons-beanutils2.java8.patch > > > BeanUtils1 supports automatic type conversion when setting properties. This > should be added to BeanUtils2. > A problem of the implementation of BeanUtils1 is, that the registry of > converts is cached in the BeanUtils class. BeanUtils2 should provide an API > for creating new instances of the o.a.c.beanutils2.BeanUtils with a > customized typ conversion registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (SANDBOX-501) Add configurable type conversion support
[ https://issues.apache.org/jira/browse/SANDBOX-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew P Mann updated SANDBOX-501: --- Attachment: commons-beanutils2.2015-11-13.patch > Add configurable type conversion support > > > Key: SANDBOX-501 > URL: https://issues.apache.org/jira/browse/SANDBOX-501 > Project: Commons Sandbox > Issue Type: New Feature > Components: BeanUtils2 >Reporter: Benedikt Ritter > Attachments: commons-beanutils2.2015-11-13.patch, > commons-beanutils2.java8.patch > > > BeanUtils1 supports automatic type conversion when setting properties. This > should be added to BeanUtils2. > A problem of the implementation of BeanUtils1 is, that the registry of > converts is cached in the BeanUtils class. BeanUtils2 should provide an API > for creating new instances of the o.a.c.beanutils2.BeanUtils with a > customized typ conversion registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IMAGING-175) Check download release
Thomas Hartwig created IMAGING-175: -- Summary: Check download release Key: IMAGING-175 URL: https://issues.apache.org/jira/browse/IMAGING-175 Project: Commons Imaging Issue Type: Bug Reporter: Thomas Hartwig I am interesting in evaluating Commons Imaging, however there is only the incubating release available 0.97 for download with old naming scheme (sanselan) and strange old time stamps when extracting (2009). In the webpage there is spoke of a snapshot release pre1.0, but there is no download in no archive. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (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=15003922#comment-15003922
]
Thomas Neidhart commented on COLLECTIONS-580:
-
I prefer a fail-fast approach.
btw. a successful attack will call the transform as part of the call to
readObject, thus it will fail during de-serialization.
> 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=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] [Commented] (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=15003970#comment-15003970
]
Thomas Neidhart commented on COLLECTIONS-580:
-
{quote}
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).
{quote}
I did not question your approach, I wanted to point out that in the attack
vector, i.e. InvokerTransformer#transform will already be called during
de-serialization (of another object).
{quote}
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.
{quote}
We are trying to do this, but the rationale is as follows: if an application
uses the unsafe classes in a legit way, i.e. will de-serialize them from a
trusted source, the application will most likely also *use* these objects in a
way or another. It means that the application will fail in any way, but it will
be easier to spot/fix if it happens already during the de-serialization, but
please correct me if you have a use-case where your approach would be more
suitable.
{quote}
For newer versions (major/minor) I would agree to your fail-fast approach. Here
I would also suggest to remove the complete Serialization feature.
{quote}
This is indeed the plan, for the 4.1 release we will hopefully remove the
Serializable interface from the unsafe classes.
> 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] [Commented] (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=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)
