[collection][security] InvokerTransformer missused in java object serialisation exploits

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[collection][security] InvokerTransformer missused in java object serialisation exploits

Bernd Eckenfels
ello,

I came across this article:

http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/

It describes attacks against common Java applications with
pre-authentication requests using malicious Java Object serialisation.
It builds upon the work of Gabriel Lawrence (@gebl) and Chris Frohoff
(@frohoff) (presented on January 28th, 2015, “Marshalling Pickles”
given at AppSecCali)

http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles

The ysoserial tool has some sample payloads, two use
commons-collection oac.collections.functors.InvokerTransformer. *

https://github.com/frohoff/ysoserial/tree/master/src/main/java/ysoserial/payloads

The class itself is rather handy to break out of the readObject()
chains to execute arbitrary methods.

I do'nt recall any discussion here about this
class. Is this currently handled/reported? Of course the more general
problem is using serialisation with untusted peers, and if
commons-collection fixes this, there might still be other vectors, but
still I think it would be good to do something against that "bad press"?

Gruss
Bernd

* Another payload uses org.codehaus.groovy.runtime.MethodClosure from
Groovy or some sring AutoWire Stuff.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collection][security] InvokerTransformer missused in java object serialisation exploits

Thomas Neidhart
On 11/06/2015 10:25 PM, Bernd Eckenfels wrote:

> ello,
>
> I came across this article:
>
> http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
>
> It describes attacks against common Java applications with
> pre-authentication requests using malicious Java Object serialisation.
> It builds upon the work of Gabriel Lawrence (@gebl) and Chris Frohoff
> (@frohoff) (presented on January 28th, 2015, “Marshalling Pickles”
> given at AppSecCali)
>
> http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles
>
> The ysoserial tool has some sample payloads, two use
> commons-collection oac.collections.functors.InvokerTransformer. *
>
> https://github.com/frohoff/ysoserial/tree/master/src/main/java/ysoserial/payloads
>
> The class itself is rather handy to break out of the readObject()
> chains to execute arbitrary methods.
>
> I do'nt recall any discussion here about this
> class. Is this currently handled/reported? Of course the more general
> problem is using serialisation with untusted peers, and if
> commons-collection fixes this, there might still be other vectors, but
> still I think it would be good to do something against that "bad press"?

I was not aware of this yet, thanks for the pointers.

If we would remove the problematic classes and release a new collections
version (for the 3.x or 4.x branch) we would break source and binary
compatibility.

It might be acceptable/doable to release a collections version with an
additional maven classifier (e.g. -hardened) that removes the relevant
classes and explain the compatibility issues in detail in the release
notes. What do others think about something like that?

btw. with Java 8 you can do similar things by using serialized method
references. I did create a very simple example to illustrate the issue:

public class MyTest {

        public static void main(String[] args) throws Exception {
    final SAM1 m1 = (SAM1 & Serializable) Runtime::getRuntime;
    final SAM2 m2 = (SAM2 & Serializable) Runtime::exec;
   
    Transformer t1 = (Transformer & Serializable) (input) -> m1.action();
    Transformer t2 = (Transformer & Serializable) (input) -> {
    try {
    Process p = m2.action((Runtime) input, "ls");
   
    String line;
    StringBuilder output = new StringBuilder();
    BufferedReader reader = new BufferedReader(new
InputStreamReader(p.getInputStream()));
    while ((line = reader.readLine()) != null) {
       output.append(line);
       output.append("\n");
    }
    reader.close();
    return output.toString();
    } catch (IOException e) {
    return null;
    }
    };

    ChainedTransformer chain = new ChainedTransformer(t1, t2);
    TransformedList list = TransformedList.transformedList(new
ArrayList(), chain);

        FileOutputStream fos = new FileOutputStream("test.ser");
        ObjectOutputStream os = new ObjectOutputStream(fos);
        os.writeObject(list);
        os.close();

        FileInputStream fis = new FileInputStream("test.ser");
        ObjectInputStream ois = new ObjectInputStream(fis);

        List l2 = (List)ois.readObject();

        l2.add(1);

        //Print the result
        System.out.println(l2);
        ois.close();
    }

    interface SAM1 {
        Runtime action();
    }

    interface SAM2 {
        Process action(Runtime r, String s) throws IOException;
    }

}


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collection][security] InvokerTransformer missused in java object serialisation exploits

Thomas Neidhart
On 11/07/2015 12:56 AM, Thomas Neidhart wrote:

> On 11/06/2015 10:25 PM, Bernd Eckenfels wrote:
>> ello,
>>
>> I came across this article:
>>
>> http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
>>
>> It describes attacks against common Java applications with
>> pre-authentication requests using malicious Java Object serialisation.
>> It builds upon the work of Gabriel Lawrence (@gebl) and Chris Frohoff
>> (@frohoff) (presented on January 28th, 2015, “Marshalling Pickles”
>> given at AppSecCali)
>>
>> http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles
>>
>> The ysoserial tool has some sample payloads, two use
>> commons-collection oac.collections.functors.InvokerTransformer. *
>>
>> https://github.com/frohoff/ysoserial/tree/master/src/main/java/ysoserial/payloads
>>
>> The class itself is rather handy to break out of the readObject()
>> chains to execute arbitrary methods.
>>
>> I do'nt recall any discussion here about this
>> class. Is this currently handled/reported? Of course the more general
>> problem is using serialisation with untusted peers, and if
>> commons-collection fixes this, there might still be other vectors, but
>> still I think it would be good to do something against that "bad press"?
>
> I was not aware of this yet, thanks for the pointers.
>
> If we would remove the problematic classes and release a new collections
> version (for the 3.x or 4.x branch) we would break source and binary
> compatibility.
>
> It might be acceptable/doable to release a collections version with an
> additional maven classifier (e.g. -hardened) that removes the relevant
> classes and explain the compatibility issues in detail in the release
> notes. What do others think about something like that?
>
> btw. with Java 8 you can do similar things by using serialized method
> references. I did create a very simple example to illustrate the issue:
>
> public class MyTest {
>
> public static void main(String[] args) throws Exception {
>     final SAM1 m1 = (SAM1 & Serializable) Runtime::getRuntime;
>     final SAM2 m2 = (SAM2 & Serializable) Runtime::exec;
>    
>     Transformer t1 = (Transformer & Serializable) (input) -> m1.action();
>     Transformer t2 = (Transformer & Serializable) (input) -> {
>     try {
>     Process p = m2.action((Runtime) input, "ls");
>    
>     String line;
>     StringBuilder output = new StringBuilder();
>     BufferedReader reader = new BufferedReader(new
> InputStreamReader(p.getInputStream()));
>     while ((line = reader.readLine()) != null) {
>        output.append(line);
>        output.append("\n");
>     }
>     reader.close();
>     return output.toString();
>     } catch (IOException e) {
>     return null;
>     }
>     };
>
>     ChainedTransformer chain = new ChainedTransformer(t1, t2);
>     TransformedList list = TransformedList.transformedList(new
> ArrayList(), chain);
>
>         FileOutputStream fos = new FileOutputStream("test.ser");
>         ObjectOutputStream os = new ObjectOutputStream(fos);
>         os.writeObject(list);
>         os.close();
>
>         FileInputStream fis = new FileInputStream("test.ser");
>         ObjectInputStream ois = new ObjectInputStream(fis);
>
>         List l2 = (List)ois.readObject();
>
>         l2.add(1);
>
>         //Print the result
>         System.out.println(l2);
>         ois.close();
>     }
>
>     interface SAM1 {
> Runtime action();
>     }
>
>     interface SAM2 {
>         Process action(Runtime r, String s) throws IOException;
>     }
>

I was a bit too fast with this. This example will only work if the
remote site has the same code otherwise the lambda functions can not be
de-serialized.

Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collection][security] InvokerTransformer missused in java object serialisation exploits

Bernd Eckenfels
In reply to this post by Thomas Neidhart
Hello,

I tried to raise that concern in the message already, but it is probably
worth repeating it explicitly: this is not a real bug
in the Commons-Collection class, and it might not be worse fixing it, as
there are possibly tons of other vectors. This was also addressed by the
original authors in the talk and even here on Twitter:

https://twitter.com/gebl/status/662754611304996866

however, as the "foxglove" article shows, people still point at the
apache project, and after all it is good pratice to reduce footprints
and attack surfaces.

So it seems to be a good idea to discuss some hardening. Unfortunatelly
having a hardened distribution with only this one class removed might
be a bit overkill. Are there other candidates to be left out in such a
more specific distribution? Maybe everything proxy/reflection related?

Both sample payloads have "gadget chains" which do start (readObject())
in JCL classes and then use pretty generic interfaces like Annotations
or Comparators, so there is really no link between the types and the
specific weakness.

Greetings
Bernd


 Am Sat, 7 Nov 2015 00:56:00 +0100
schrieb Thomas Neidhart <[hidden email]>:

> On 11/06/2015 10:25 PM, Bernd Eckenfels wrote:
> > ello,
> >
> > I came across this article:
> >
> > http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
> >
> > It describes attacks against common Java applications with
> > pre-authentication requests using malicious Java Object
> > serialisation. It builds upon the work of Gabriel Lawrence (@gebl)
> > and Chris Frohoff (@frohoff) (presented on January 28th, 2015,
> > “Marshalling Pickles” given at AppSecCali)
> >
> > http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-pickles
> >
> > The ysoserial tool has some sample payloads, two use
> > commons-collection oac.collections.functors.InvokerTransformer. *
> >
> > https://github.com/frohoff/ysoserial/tree/master/src/main/java/ysoserial/payloads
> >
> > The class itself is rather handy to break out of the readObject()
> > chains to execute arbitrary methods.
> >
> > I do'nt recall any discussion here about this
> > class. Is this currently handled/reported? Of course the more
> > general problem is using serialisation with untusted peers, and if
> > commons-collection fixes this, there might still be other vectors,
> > but still I think it would be good to do something against that
> > "bad press"?
>
> I was not aware of this yet, thanks for the pointers.
>
> If we would remove the problematic classes and release a new
> collections version (for the 3.x or 4.x branch) we would break source
> and binary compatibility.
>
> It might be acceptable/doable to release a collections version with an
> additional maven classifier (e.g. -hardened) that removes the relevant
> classes and explain the compatibility issues in detail in the release
> notes. What do others think about something like that?
...

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collection][security] InvokerTransformer missused in java object serialisation exploits

Thomas Neidhart
On 11/07/2015 04:25 AM, Bernd Eckenfels wrote:

> Hello,
>
> I tried to raise that concern in the message already, but it is probably
> worth repeating it explicitly: this is not a real bug
> in the Commons-Collection class, and it might not be worse fixing it, as
> there are possibly tons of other vectors. This was also addressed by the
> original authors in the talk and even here on Twitter:
>
> https://twitter.com/gebl/status/662754611304996866
>
> however, as the "foxglove" article shows, people still point at the
> apache project, and after all it is good pratice to reduce footprints
> and attack surfaces.

it is clear that the InvokerTransformer by itself does not have a bug,
but due to the way how java serialization is applied and considering the
fact that at least collections-3.2.1 is used *a lot* it would make sense
to provide a hardened version of collections to give people a chance to
easily avoid this line of attack in their application.

Instead of removing the class we could prevent de-serialization of it in
the hardened jar. This would not break b/c and it is very unlikely that
the InvokerTransformer is serialized in legit ways.

Other ways to fix this issue seem to be quite complex, i.e. change the
way serialization is performed (use whitelisting, ...), and will most
likely not be executed in a timely manner. I wonder if some people
already ship a collections version with this class being
removed/manipulated, or use a runtime weaving technique to remove the
serialization support from it?

Setting up a reasonable security policy for this line of attack also
seems to be futile as it would have to be so restrictive that most
applications probably wont work anymore.

> So it seems to be a good idea to discuss some hardening. Unfortunatelly
> having a hardened distribution with only this one class removed might
> be a bit overkill. Are there other candidates to be left out in such a
> more specific distribution? Maybe everything proxy/reflection related?

I checked the codebase, and there are other Invoker* type classes but
they all use internally the InvokerTransformer.

> Both sample payloads have "gadget chains" which do start (readObject())
> in JCL classes and then use pretty generic interfaces like Annotations
> or Comparators, so there is really no link between the types and the
> specific weakness.

I did not see JCL (commons logging?) used in the gadget chains.

btw. the technique using the TransformerImpl from xalan (which is part
of the oracle/openjdk jre) is really scary as it allows an attacker to
inject arbitrary bytecode.

Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collection][security] InvokerTransformer missused in java object serialisation exploits

Mark Thomas
On 07/11/2015 10:13, Thomas Neidhart wrote:

> On 11/07/2015 04:25 AM, Bernd Eckenfels wrote:
>> Hello,
>>
>> I tried to raise that concern in the message already, but it is probably
>> worth repeating it explicitly: this is not a real bug
>> in the Commons-Collection class, and it might not be worse fixing it, as
>> there are possibly tons of other vectors. This was also addressed by the
>> original authors in the talk and even here on Twitter:
>>
>> https://twitter.com/gebl/status/662754611304996866
>>
>> however, as the "foxglove" article shows, people still point at the
>> apache project, and after all it is good pratice to reduce footprints
>> and attack surfaces.
>
> it is clear that the InvokerTransformer by itself does not have a bug,
> but due to the way how java serialization is applied and considering the
> fact that at least collections-3.2.1 is used *a lot* it would make sense
> to provide a hardened version of collections to give people a chance to
> easily avoid this line of attack in their application.
>
> Instead of removing the class we could prevent de-serialization of it in
> the hardened jar. This would not break b/c and it is very unlikely that
> the InvokerTransformer is serialized in legit ways.

Rather than having hardened vs unhardened JARs, it would probably be
better to use a system property to enable/disable the behaviour. I don't
know the code or the vulnerability well enough to know exactly where to
put this switch so it prevents the attack but has minimal impact on
other uses.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collection][security] InvokerTransformer missused in java object serialisation exploits

Bernd Eckenfels
In reply to this post by Thomas Neidhart
>> Both sample payloads have "gadget chains" which do start (readObject())
>> in JCL classes and then use pretty generic interfaces like Annotations
>> or Comparators, so there is really no link between the types and the
>> specific weakness.

> I did not see JCL (commons logging?) used in the gadget chains.

JCL = Jaca Class Library (in this case ,)

--
http://bernd.eckenfels.net

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collection][security] InvokerTransformer missused in java object serialisation exploits

Thomas Neidhart
In reply to this post by Mark Thomas
On 11/07/2015 11:19 AM, Mark Thomas wrote:

> On 07/11/2015 10:13, Thomas Neidhart wrote:
>> On 11/07/2015 04:25 AM, Bernd Eckenfels wrote:
>>> Hello,
>>>
>>> I tried to raise that concern in the message already, but it is probably
>>> worth repeating it explicitly: this is not a real bug
>>> in the Commons-Collection class, and it might not be worse fixing it, as
>>> there are possibly tons of other vectors. This was also addressed by the
>>> original authors in the talk and even here on Twitter:
>>>
>>> https://twitter.com/gebl/status/662754611304996866
>>>
>>> however, as the "foxglove" article shows, people still point at the
>>> apache project, and after all it is good pratice to reduce footprints
>>> and attack surfaces.
>>
>> it is clear that the InvokerTransformer by itself does not have a bug,
>> but due to the way how java serialization is applied and considering the
>> fact that at least collections-3.2.1 is used *a lot* it would make sense
>> to provide a hardened version of collections to give people a chance to
>> easily avoid this line of attack in their application.
>>
>> Instead of removing the class we could prevent de-serialization of it in
>> the hardened jar. This would not break b/c and it is very unlikely that
>> the InvokerTransformer is serialized in legit ways.
>
> Rather than having hardened vs unhardened JARs, it would probably be
> better to use a system property to enable/disable the behaviour. I don't
> know the code or the vulnerability well enough to know exactly where to
> put this switch so it prevents the attack but has minimal impact on
> other uses.

my idea was to have a binary compatible drop-in replacement that does
not require any configuration, so that people that happen to have
commons-collections 3.2.1 in their classpath can replace it with a
hardened version.

But I am open to other suggestions, in the end it is important to do
what affected users would like to have to mitigate the problem.

Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collection][security] InvokerTransformer missused in java object serialisation exploits

Mark Thomas
On 08/11/2015 10:18, Thomas Neidhart wrote:

> On 11/07/2015 11:19 AM, Mark Thomas wrote:
>> On 07/11/2015 10:13, Thomas Neidhart wrote:
>>> On 11/07/2015 04:25 AM, Bernd Eckenfels wrote:
>>>> Hello,
>>>>
>>>> I tried to raise that concern in the message already, but it is probably
>>>> worth repeating it explicitly: this is not a real bug
>>>> in the Commons-Collection class, and it might not be worse fixing it, as
>>>> there are possibly tons of other vectors. This was also addressed by the
>>>> original authors in the talk and even here on Twitter:
>>>>
>>>> https://twitter.com/gebl/status/662754611304996866
>>>>
>>>> however, as the "foxglove" article shows, people still point at the
>>>> apache project, and after all it is good pratice to reduce footprints
>>>> and attack surfaces.
>>>
>>> it is clear that the InvokerTransformer by itself does not have a bug,
>>> but due to the way how java serialization is applied and considering the
>>> fact that at least collections-3.2.1 is used *a lot* it would make sense
>>> to provide a hardened version of collections to give people a chance to
>>> easily avoid this line of attack in their application.
>>>
>>> Instead of removing the class we could prevent de-serialization of it in
>>> the hardened jar. This would not break b/c and it is very unlikely that
>>> the InvokerTransformer is serialized in legit ways.
>>
>> Rather than having hardened vs unhardened JARs, it would probably be
>> better to use a system property to enable/disable the behaviour. I don't
>> know the code or the vulnerability well enough to know exactly where to
>> put this switch so it prevents the attack but has minimal impact on
>> other uses.
>
> my idea was to have a binary compatible drop-in replacement that does
> not require any configuration, so that people that happen to have
> commons-collections 3.2.1 in their classpath can replace it with a
> hardened version.
>
> But I am open to other suggestions, in the end it is important to do
> what affected users would like to have to mitigate the problem.

My main concern with a hardened JAR is that, while with just this
vulnerability, we end up with two JARs but how many JARs will we end up
with 3 or 4 vulnerabilities down the line. Particularly when fixing a
vulnerability means breaking functionality. I think system properties
scale better.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collection][security] InvokerTransformer missused in java object serialisation exploits

Thomas Neidhart
On 11/08/2015 01:32 PM, Mark Thomas wrote:

> On 08/11/2015 10:18, Thomas Neidhart wrote:
>> On 11/07/2015 11:19 AM, Mark Thomas wrote:
>>> On 07/11/2015 10:13, Thomas Neidhart wrote:
>>>> On 11/07/2015 04:25 AM, Bernd Eckenfels wrote:
>>>>> Hello,
>>>>>
>>>>> I tried to raise that concern in the message already, but it is probably
>>>>> worth repeating it explicitly: this is not a real bug
>>>>> in the Commons-Collection class, and it might not be worse fixing it, as
>>>>> there are possibly tons of other vectors. This was also addressed by the
>>>>> original authors in the talk and even here on Twitter:
>>>>>
>>>>> https://twitter.com/gebl/status/662754611304996866
>>>>>
>>>>> however, as the "foxglove" article shows, people still point at the
>>>>> apache project, and after all it is good pratice to reduce footprints
>>>>> and attack surfaces.
>>>>
>>>> it is clear that the InvokerTransformer by itself does not have a bug,
>>>> but due to the way how java serialization is applied and considering the
>>>> fact that at least collections-3.2.1 is used *a lot* it would make sense
>>>> to provide a hardened version of collections to give people a chance to
>>>> easily avoid this line of attack in their application.
>>>>
>>>> Instead of removing the class we could prevent de-serialization of it in
>>>> the hardened jar. This would not break b/c and it is very unlikely that
>>>> the InvokerTransformer is serialized in legit ways.
>>>
>>> Rather than having hardened vs unhardened JARs, it would probably be
>>> better to use a system property to enable/disable the behaviour. I don't
>>> know the code or the vulnerability well enough to know exactly where to
>>> put this switch so it prevents the attack but has minimal impact on
>>> other uses.
>>
>> my idea was to have a binary compatible drop-in replacement that does
>> not require any configuration, so that people that happen to have
>> commons-collections 3.2.1 in their classpath can replace it with a
>> hardened version.
>>
>> But I am open to other suggestions, in the end it is important to do
>> what affected users would like to have to mitigate the problem.
>
> My main concern with a hardened JAR is that, while with just this
> vulnerability, we end up with two JARs but how many JARs will we end up
> with 3 or 4 vulnerabilities down the line. Particularly when fixing a
> vulnerability means breaking functionality. I think system properties
> scale better.

with the default being: do not de-serialize InvokerTransformer?
Then I would be ok going that route.

Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collection][security] InvokerTransformer missused in java object serialisation exploits

sebb-2-2
In reply to this post by Mark Thomas
On 8 November 2015 at 12:32, Mark Thomas <[hidden email]> wrote:

> On 08/11/2015 10:18, Thomas Neidhart wrote:
>> On 11/07/2015 11:19 AM, Mark Thomas wrote:
>>> On 07/11/2015 10:13, Thomas Neidhart wrote:
>>>> On 11/07/2015 04:25 AM, Bernd Eckenfels wrote:
>>>>> Hello,
>>>>>
>>>>> I tried to raise that concern in the message already, but it is probably
>>>>> worth repeating it explicitly: this is not a real bug
>>>>> in the Commons-Collection class, and it might not be worse fixing it, as
>>>>> there are possibly tons of other vectors. This was also addressed by the
>>>>> original authors in the talk and even here on Twitter:
>>>>>
>>>>> https://twitter.com/gebl/status/662754611304996866
>>>>>
>>>>> however, as the "foxglove" article shows, people still point at the
>>>>> apache project, and after all it is good pratice to reduce footprints
>>>>> and attack surfaces.
>>>>
>>>> it is clear that the InvokerTransformer by itself does not have a bug,
>>>> but due to the way how java serialization is applied and considering the
>>>> fact that at least collections-3.2.1 is used *a lot* it would make sense
>>>> to provide a hardened version of collections to give people a chance to
>>>> easily avoid this line of attack in their application.
>>>>
>>>> Instead of removing the class we could prevent de-serialization of it in
>>>> the hardened jar. This would not break b/c and it is very unlikely that
>>>> the InvokerTransformer is serialized in legit ways.
>>>
>>> Rather than having hardened vs unhardened JARs, it would probably be
>>> better to use a system property to enable/disable the behaviour. I don't
>>> know the code or the vulnerability well enough to know exactly where to
>>> put this switch so it prevents the attack but has minimal impact on
>>> other uses.
>>
>> my idea was to have a binary compatible drop-in replacement that does
>> not require any configuration, so that people that happen to have
>> commons-collections 3.2.1 in their classpath can replace it with a
>> hardened version.
>>
>> But I am open to other suggestions, in the end it is important to do
>> what affected users would like to have to mitigate the problem.
>
> My main concern with a hardened JAR is that, while with just this
> vulnerability, we end up with two JARs but how many JARs will we end up
> with 3 or 4 vulnerabilities down the line. Particularly when fixing a
> vulnerability means breaking functionality. I think system properties
> scale better.

But is there a use case for partially hardened jars?
Surely if there are additional vulnerabilities they need to be fixed as well?

Using system properties simpifies things for Commons developers,
however it makes it harder for consumers, as they have to ensure that
the property is set.
This may be hard to check if the jar is part of a large system.

Though it would allow for certain vulnerabilities to be disabled by
default (i.e.one has set a property to enable the risky code - [*])
and others only on demand.

[*] This approach is already taken by the JDK with
sun.net.http.allowRestrictedHeaders
See: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6996110

> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collection][security] InvokerTransformer missused in java object serialisation exploits

jochen-2
I like the property based approach. In particular, because we can
evaltuate that property within

    private void readObject

Or, in other words: We can ship a jar that has the vulnerability
disabled by default (property isn't set). However, if the user
attempts to deserialize an InvokerTransformer, he or she gets a clear
and loud exception, that advices what to do (set the property). Should
be a solution that makes everyone happy in the medium term.

Jochen


On Sun, Nov 8, 2015 at 3:30 PM, sebb <[hidden email]> wrote:

> On 8 November 2015 at 12:32, Mark Thomas <[hidden email]> wrote:
>> On 08/11/2015 10:18, Thomas Neidhart wrote:
>>> On 11/07/2015 11:19 AM, Mark Thomas wrote:
>>>> On 07/11/2015 10:13, Thomas Neidhart wrote:
>>>>> On 11/07/2015 04:25 AM, Bernd Eckenfels wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I tried to raise that concern in the message already, but it is probably
>>>>>> worth repeating it explicitly: this is not a real bug
>>>>>> in the Commons-Collection class, and it might not be worse fixing it, as
>>>>>> there are possibly tons of other vectors. This was also addressed by the
>>>>>> original authors in the talk and even here on Twitter:
>>>>>>
>>>>>> https://twitter.com/gebl/status/662754611304996866
>>>>>>
>>>>>> however, as the "foxglove" article shows, people still point at the
>>>>>> apache project, and after all it is good pratice to reduce footprints
>>>>>> and attack surfaces.
>>>>>
>>>>> it is clear that the InvokerTransformer by itself does not have a bug,
>>>>> but due to the way how java serialization is applied and considering the
>>>>> fact that at least collections-3.2.1 is used *a lot* it would make sense
>>>>> to provide a hardened version of collections to give people a chance to
>>>>> easily avoid this line of attack in their application.
>>>>>
>>>>> Instead of removing the class we could prevent de-serialization of it in
>>>>> the hardened jar. This would not break b/c and it is very unlikely that
>>>>> the InvokerTransformer is serialized in legit ways.
>>>>
>>>> Rather than having hardened vs unhardened JARs, it would probably be
>>>> better to use a system property to enable/disable the behaviour. I don't
>>>> know the code or the vulnerability well enough to know exactly where to
>>>> put this switch so it prevents the attack but has minimal impact on
>>>> other uses.
>>>
>>> my idea was to have a binary compatible drop-in replacement that does
>>> not require any configuration, so that people that happen to have
>>> commons-collections 3.2.1 in their classpath can replace it with a
>>> hardened version.
>>>
>>> But I am open to other suggestions, in the end it is important to do
>>> what affected users would like to have to mitigate the problem.
>>
>> My main concern with a hardened JAR is that, while with just this
>> vulnerability, we end up with two JARs but how many JARs will we end up
>> with 3 or 4 vulnerabilities down the line. Particularly when fixing a
>> vulnerability means breaking functionality. I think system properties
>> scale better.
>
> But is there a use case for partially hardened jars?
> Surely if there are additional vulnerabilities they need to be fixed as well?
>
> Using system properties simpifies things for Commons developers,
> however it makes it harder for consumers, as they have to ensure that
> the property is set.
> This may be hard to check if the jar is part of a large system.
>
> Though it would allow for certain vulnerabilities to be disabled by
> default (i.e.one has set a property to enable the risky code - [*])
> and others only on demand.
>
> [*] This approach is already taken by the JDK with
> sun.net.http.allowRestrictedHeaders
> See: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6996110
>
>> Mark
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>



--
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collection][security] InvokerTransformer missused in java object serialisation exploits

garydgregory
I like the property option as a stopgap.

Should we add a programatic option so that programmers can also control
this on a per invoker basis?

Gary
On Nov 8, 2015 6:43 AM, "Jochen Wiedmann" <[hidden email]> wrote:

> I like the property based approach. In particular, because we can
> evaltuate that property within
>
>     private void readObject
>
> Or, in other words: We can ship a jar that has the vulnerability
> disabled by default (property isn't set). However, if the user
> attempts to deserialize an InvokerTransformer, he or she gets a clear
> and loud exception, that advices what to do (set the property). Should
> be a solution that makes everyone happy in the medium term.
>
> Jochen
>
>
> On Sun, Nov 8, 2015 at 3:30 PM, sebb <[hidden email]> wrote:
> > On 8 November 2015 at 12:32, Mark Thomas <[hidden email]> wrote:
> >> On 08/11/2015 10:18, Thomas Neidhart wrote:
> >>> On 11/07/2015 11:19 AM, Mark Thomas wrote:
> >>>> On 07/11/2015 10:13, Thomas Neidhart wrote:
> >>>>> On 11/07/2015 04:25 AM, Bernd Eckenfels wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> I tried to raise that concern in the message already, but it is
> probably
> >>>>>> worth repeating it explicitly: this is not a real bug
> >>>>>> in the Commons-Collection class, and it might not be worse fixing
> it, as
> >>>>>> there are possibly tons of other vectors. This was also addressed
> by the
> >>>>>> original authors in the talk and even here on Twitter:
> >>>>>>
> >>>>>> https://twitter.com/gebl/status/662754611304996866
> >>>>>>
> >>>>>> however, as the "foxglove" article shows, people still point at the
> >>>>>> apache project, and after all it is good pratice to reduce
> footprints
> >>>>>> and attack surfaces.
> >>>>>
> >>>>> it is clear that the InvokerTransformer by itself does not have a
> bug,
> >>>>> but due to the way how java serialization is applied and considering
> the
> >>>>> fact that at least collections-3.2.1 is used *a lot* it would make
> sense
> >>>>> to provide a hardened version of collections to give people a chance
> to
> >>>>> easily avoid this line of attack in their application.
> >>>>>
> >>>>> Instead of removing the class we could prevent de-serialization of
> it in
> >>>>> the hardened jar. This would not break b/c and it is very unlikely
> that
> >>>>> the InvokerTransformer is serialized in legit ways.
> >>>>
> >>>> Rather than having hardened vs unhardened JARs, it would probably be
> >>>> better to use a system property to enable/disable the behaviour. I
> don't
> >>>> know the code or the vulnerability well enough to know exactly where
> to
> >>>> put this switch so it prevents the attack but has minimal impact on
> >>>> other uses.
> >>>
> >>> my idea was to have a binary compatible drop-in replacement that does
> >>> not require any configuration, so that people that happen to have
> >>> commons-collections 3.2.1 in their classpath can replace it with a
> >>> hardened version.
> >>>
> >>> But I am open to other suggestions, in the end it is important to do
> >>> what affected users would like to have to mitigate the problem.
> >>
> >> My main concern with a hardened JAR is that, while with just this
> >> vulnerability, we end up with two JARs but how many JARs will we end up
> >> with 3 or 4 vulnerabilities down the line. Particularly when fixing a
> >> vulnerability means breaking functionality. I think system properties
> >> scale better.
> >
> > But is there a use case for partially hardened jars?
> > Surely if there are additional vulnerabilities they need to be fixed as
> well?
> >
> > Using system properties simpifies things for Commons developers,
> > however it makes it harder for consumers, as they have to ensure that
> > the property is set.
> > This may be hard to check if the jar is part of a large system.
> >
> > Though it would allow for certain vulnerabilities to be disabled by
> > default (i.e.one has set a property to enable the risky code - [*])
> > and others only on demand.
> >
> > [*] This approach is already taken by the JDK with
> > sun.net.http.allowRestrictedHeaders
> > See: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6996110
> >
> >> Mark
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
>
> --
> The next time you hear: "Don't reinvent the wheel!"
>
>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [collection][security] InvokerTransformer missused in java object serialisation exploits

jochen-2
Makes sense.


On Sun, Nov 8, 2015 at 3:47 PM, Gary Gregory <[hidden email]> wrote:

> I like the property option as a stopgap.
>
> Should we add a programatic option so that programmers can also control
> this on a per invoker basis?
>
> Gary
> On Nov 8, 2015 6:43 AM, "Jochen Wiedmann" <[hidden email]> wrote:
>
>> I like the property based approach. In particular, because we can
>> evaltuate that property within
>>
>>     private void readObject
>>
>> Or, in other words: We can ship a jar that has the vulnerability
>> disabled by default (property isn't set). However, if the user
>> attempts to deserialize an InvokerTransformer, he or she gets a clear
>> and loud exception, that advices what to do (set the property). Should
>> be a solution that makes everyone happy in the medium term.
>>
>> Jochen
>>
>>
>> On Sun, Nov 8, 2015 at 3:30 PM, sebb <[hidden email]> wrote:
>> > On 8 November 2015 at 12:32, Mark Thomas <[hidden email]> wrote:
>> >> On 08/11/2015 10:18, Thomas Neidhart wrote:
>> >>> On 11/07/2015 11:19 AM, Mark Thomas wrote:
>> >>>> On 07/11/2015 10:13, Thomas Neidhart wrote:
>> >>>>> On 11/07/2015 04:25 AM, Bernd Eckenfels wrote:
>> >>>>>> Hello,
>> >>>>>>
>> >>>>>> I tried to raise that concern in the message already, but it is
>> probably
>> >>>>>> worth repeating it explicitly: this is not a real bug
>> >>>>>> in the Commons-Collection class, and it might not be worse fixing
>> it, as
>> >>>>>> there are possibly tons of other vectors. This was also addressed
>> by the
>> >>>>>> original authors in the talk and even here on Twitter:
>> >>>>>>
>> >>>>>> https://twitter.com/gebl/status/662754611304996866
>> >>>>>>
>> >>>>>> however, as the "foxglove" article shows, people still point at the
>> >>>>>> apache project, and after all it is good pratice to reduce
>> footprints
>> >>>>>> and attack surfaces.
>> >>>>>
>> >>>>> it is clear that the InvokerTransformer by itself does not have a
>> bug,
>> >>>>> but due to the way how java serialization is applied and considering
>> the
>> >>>>> fact that at least collections-3.2.1 is used *a lot* it would make
>> sense
>> >>>>> to provide a hardened version of collections to give people a chance
>> to
>> >>>>> easily avoid this line of attack in their application.
>> >>>>>
>> >>>>> Instead of removing the class we could prevent de-serialization of
>> it in
>> >>>>> the hardened jar. This would not break b/c and it is very unlikely
>> that
>> >>>>> the InvokerTransformer is serialized in legit ways.
>> >>>>
>> >>>> Rather than having hardened vs unhardened JARs, it would probably be
>> >>>> better to use a system property to enable/disable the behaviour. I
>> don't
>> >>>> know the code or the vulnerability well enough to know exactly where
>> to
>> >>>> put this switch so it prevents the attack but has minimal impact on
>> >>>> other uses.
>> >>>
>> >>> my idea was to have a binary compatible drop-in replacement that does
>> >>> not require any configuration, so that people that happen to have
>> >>> commons-collections 3.2.1 in their classpath can replace it with a
>> >>> hardened version.
>> >>>
>> >>> But I am open to other suggestions, in the end it is important to do
>> >>> what affected users would like to have to mitigate the problem.
>> >>
>> >> My main concern with a hardened JAR is that, while with just this
>> >> vulnerability, we end up with two JARs but how many JARs will we end up
>> >> with 3 or 4 vulnerabilities down the line. Particularly when fixing a
>> >> vulnerability means breaking functionality. I think system properties
>> >> scale better.
>> >
>> > But is there a use case for partially hardened jars?
>> > Surely if there are additional vulnerabilities they need to be fixed as
>> well?
>> >
>> > Using system properties simpifies things for Commons developers,
>> > however it makes it harder for consumers, as they have to ensure that
>> > the property is set.
>> > This may be hard to check if the jar is part of a large system.
>> >
>> > Though it would allow for certain vulnerabilities to be disabled by
>> > default (i.e.one has set a property to enable the risky code - [*])
>> > and others only on demand.
>> >
>> > [*] This approach is already taken by the JDK with
>> > sun.net.http.allowRestrictedHeaders
>> > See: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6996110
>> >
>> >> Mark
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>>
>>
>>
>> --
>> The next time you hear: "Don't reinvent the wheel!"
>>
>>
>> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>



--
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collection][security] InvokerTransformer missused in java object serialisation exploits

Matt Benson-2
I'm only tangentially following this, but if the problem is that an
attacker can supply malicious bytecode, then wouldn't a programmatic e.g.
property be just as easy [for an attacker] to pass in? This would need to
be a transient property, if included, right?

Matt
On Nov 8, 2015 8:50 AM, "Jochen Wiedmann" <[hidden email]> wrote:

> Makes sense.
>
>
> On Sun, Nov 8, 2015 at 3:47 PM, Gary Gregory <[hidden email]>
> wrote:
> > I like the property option as a stopgap.
> >
> > Should we add a programatic option so that programmers can also control
> > this on a per invoker basis?
> >
> > Gary
> > On Nov 8, 2015 6:43 AM, "Jochen Wiedmann" <[hidden email]>
> wrote:
> >
> >> I like the property based approach. In particular, because we can
> >> evaltuate that property within
> >>
> >>     private void readObject
> >>
> >> Or, in other words: We can ship a jar that has the vulnerability
> >> disabled by default (property isn't set). However, if the user
> >> attempts to deserialize an InvokerTransformer, he or she gets a clear
> >> and loud exception, that advices what to do (set the property). Should
> >> be a solution that makes everyone happy in the medium term.
> >>
> >> Jochen
> >>
> >>
> >> On Sun, Nov 8, 2015 at 3:30 PM, sebb <[hidden email]> wrote:
> >> > On 8 November 2015 at 12:32, Mark Thomas <[hidden email]> wrote:
> >> >> On 08/11/2015 10:18, Thomas Neidhart wrote:
> >> >>> On 11/07/2015 11:19 AM, Mark Thomas wrote:
> >> >>>> On 07/11/2015 10:13, Thomas Neidhart wrote:
> >> >>>>> On 11/07/2015 04:25 AM, Bernd Eckenfels wrote:
> >> >>>>>> Hello,
> >> >>>>>>
> >> >>>>>> I tried to raise that concern in the message already, but it is
> >> probably
> >> >>>>>> worth repeating it explicitly: this is not a real bug
> >> >>>>>> in the Commons-Collection class, and it might not be worse fixing
> >> it, as
> >> >>>>>> there are possibly tons of other vectors. This was also addressed
> >> by the
> >> >>>>>> original authors in the talk and even here on Twitter:
> >> >>>>>>
> >> >>>>>> https://twitter.com/gebl/status/662754611304996866
> >> >>>>>>
> >> >>>>>> however, as the "foxglove" article shows, people still point at
> the
> >> >>>>>> apache project, and after all it is good pratice to reduce
> >> footprints
> >> >>>>>> and attack surfaces.
> >> >>>>>
> >> >>>>> it is clear that the InvokerTransformer by itself does not have a
> >> bug,
> >> >>>>> but due to the way how java serialization is applied and
> considering
> >> the
> >> >>>>> fact that at least collections-3.2.1 is used *a lot* it would make
> >> sense
> >> >>>>> to provide a hardened version of collections to give people a
> chance
> >> to
> >> >>>>> easily avoid this line of attack in their application.
> >> >>>>>
> >> >>>>> Instead of removing the class we could prevent de-serialization of
> >> it in
> >> >>>>> the hardened jar. This would not break b/c and it is very unlikely
> >> that
> >> >>>>> the InvokerTransformer is serialized in legit ways.
> >> >>>>
> >> >>>> Rather than having hardened vs unhardened JARs, it would probably
> be
> >> >>>> better to use a system property to enable/disable the behaviour. I
> >> don't
> >> >>>> know the code or the vulnerability well enough to know exactly
> where
> >> to
> >> >>>> put this switch so it prevents the attack but has minimal impact on
> >> >>>> other uses.
> >> >>>
> >> >>> my idea was to have a binary compatible drop-in replacement that
> does
> >> >>> not require any configuration, so that people that happen to have
> >> >>> commons-collections 3.2.1 in their classpath can replace it with a
> >> >>> hardened version.
> >> >>>
> >> >>> But I am open to other suggestions, in the end it is important to do
> >> >>> what affected users would like to have to mitigate the problem.
> >> >>
> >> >> My main concern with a hardened JAR is that, while with just this
> >> >> vulnerability, we end up with two JARs but how many JARs will we end
> up
> >> >> with 3 or 4 vulnerabilities down the line. Particularly when fixing a
> >> >> vulnerability means breaking functionality. I think system properties
> >> >> scale better.
> >> >
> >> > But is there a use case for partially hardened jars?
> >> > Surely if there are additional vulnerabilities they need to be fixed
> as
> >> well?
> >> >
> >> > Using system properties simpifies things for Commons developers,
> >> > however it makes it harder for consumers, as they have to ensure that
> >> > the property is set.
> >> > This may be hard to check if the jar is part of a large system.
> >> >
> >> > Though it would allow for certain vulnerabilities to be disabled by
> >> > default (i.e.one has set a property to enable the risky code - [*])
> >> > and others only on demand.
> >> >
> >> > [*] This approach is already taken by the JDK with
> >> > sun.net.http.allowRestrictedHeaders
> >> > See: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6996110
> >> >
> >> >> Mark
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: [hidden email]
> >> >> For additional commands, e-mail: [hidden email]
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: [hidden email]
> >> > For additional commands, e-mail: [hidden email]
> >> >
> >>
> >>
> >>
> >> --
> >> The next time you hear: "Don't reinvent the wheel!"
> >>
> >>
> >>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
>
>
>
> --
> The next time you hear: "Don't reinvent the wheel!"
>
>
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [collection][security] InvokerTransformer missused in java object serialisation exploits

James Carman
The problem is that we provide them a means to invoke a method on an object.
On Sun, Nov 8, 2015 at 1:43 PM Matt Benson <[hidden email]> wrote:

> I'm only tangentially following this, but if the problem is that an
> attacker can supply malicious bytecode, then wouldn't a programmatic e.g.
> property be just as easy [for an attacker] to pass in? This would need to
> be a transient property, if included, right?
>
> Matt
> On Nov 8, 2015 8:50 AM, "Jochen Wiedmann" <[hidden email]>
> wrote:
>
> > Makes sense.
> >
> >
> > On Sun, Nov 8, 2015 at 3:47 PM, Gary Gregory <[hidden email]>
> > wrote:
> > > I like the property option as a stopgap.
> > >
> > > Should we add a programatic option so that programmers can also control
> > > this on a per invoker basis?
> > >
> > > Gary
> > > On Nov 8, 2015 6:43 AM, "Jochen Wiedmann" <[hidden email]>
> > wrote:
> > >
> > >> I like the property based approach. In particular, because we can
> > >> evaltuate that property within
> > >>
> > >>     private void readObject
> > >>
> > >> Or, in other words: We can ship a jar that has the vulnerability
> > >> disabled by default (property isn't set). However, if the user
> > >> attempts to deserialize an InvokerTransformer, he or she gets a clear
> > >> and loud exception, that advices what to do (set the property). Should
> > >> be a solution that makes everyone happy in the medium term.
> > >>
> > >> Jochen
> > >>
> > >>
> > >> On Sun, Nov 8, 2015 at 3:30 PM, sebb <[hidden email]> wrote:
> > >> > On 8 November 2015 at 12:32, Mark Thomas <[hidden email]> wrote:
> > >> >> On 08/11/2015 10:18, Thomas Neidhart wrote:
> > >> >>> On 11/07/2015 11:19 AM, Mark Thomas wrote:
> > >> >>>> On 07/11/2015 10:13, Thomas Neidhart wrote:
> > >> >>>>> On 11/07/2015 04:25 AM, Bernd Eckenfels wrote:
> > >> >>>>>> Hello,
> > >> >>>>>>
> > >> >>>>>> I tried to raise that concern in the message already, but it is
> > >> probably
> > >> >>>>>> worth repeating it explicitly: this is not a real bug
> > >> >>>>>> in the Commons-Collection class, and it might not be worse
> fixing
> > >> it, as
> > >> >>>>>> there are possibly tons of other vectors. This was also
> addressed
> > >> by the
> > >> >>>>>> original authors in the talk and even here on Twitter:
> > >> >>>>>>
> > >> >>>>>> https://twitter.com/gebl/status/662754611304996866
> > >> >>>>>>
> > >> >>>>>> however, as the "foxglove" article shows, people still point at
> > the
> > >> >>>>>> apache project, and after all it is good pratice to reduce
> > >> footprints
> > >> >>>>>> and attack surfaces.
> > >> >>>>>
> > >> >>>>> it is clear that the InvokerTransformer by itself does not have
> a
> > >> bug,
> > >> >>>>> but due to the way how java serialization is applied and
> > considering
> > >> the
> > >> >>>>> fact that at least collections-3.2.1 is used *a lot* it would
> make
> > >> sense
> > >> >>>>> to provide a hardened version of collections to give people a
> > chance
> > >> to
> > >> >>>>> easily avoid this line of attack in their application.
> > >> >>>>>
> > >> >>>>> Instead of removing the class we could prevent de-serialization
> of
> > >> it in
> > >> >>>>> the hardened jar. This would not break b/c and it is very
> unlikely
> > >> that
> > >> >>>>> the InvokerTransformer is serialized in legit ways.
> > >> >>>>
> > >> >>>> Rather than having hardened vs unhardened JARs, it would probably
> > be
> > >> >>>> better to use a system property to enable/disable the behaviour.
> I
> > >> don't
> > >> >>>> know the code or the vulnerability well enough to know exactly
> > where
> > >> to
> > >> >>>> put this switch so it prevents the attack but has minimal impact
> on
> > >> >>>> other uses.
> > >> >>>
> > >> >>> my idea was to have a binary compatible drop-in replacement that
> > does
> > >> >>> not require any configuration, so that people that happen to have
> > >> >>> commons-collections 3.2.1 in their classpath can replace it with a
> > >> >>> hardened version.
> > >> >>>
> > >> >>> But I am open to other suggestions, in the end it is important to
> do
> > >> >>> what affected users would like to have to mitigate the problem.
> > >> >>
> > >> >> My main concern with a hardened JAR is that, while with just this
> > >> >> vulnerability, we end up with two JARs but how many JARs will we
> end
> > up
> > >> >> with 3 or 4 vulnerabilities down the line. Particularly when
> fixing a
> > >> >> vulnerability means breaking functionality. I think system
> properties
> > >> >> scale better.
> > >> >
> > >> > But is there a use case for partially hardened jars?
> > >> > Surely if there are additional vulnerabilities they need to be fixed
> > as
> > >> well?
> > >> >
> > >> > Using system properties simpifies things for Commons developers,
> > >> > however it makes it harder for consumers, as they have to ensure
> that
> > >> > the property is set.
> > >> > This may be hard to check if the jar is part of a large system.
> > >> >
> > >> > Though it would allow for certain vulnerabilities to be disabled by
> > >> > default (i.e.one has set a property to enable the risky code - [*])
> > >> > and others only on demand.
> > >> >
> > >> > [*] This approach is already taken by the JDK with
> > >> > sun.net.http.allowRestrictedHeaders
> > >> > See: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6996110
> > >> >
> > >> >> Mark
> > >> >>
> > >> >>
> > >> >>
> ---------------------------------------------------------------------
> > >> >> To unsubscribe, e-mail: [hidden email]
> > >> >> For additional commands, e-mail: [hidden email]
> > >> >>
> > >> >
> > >> >
> ---------------------------------------------------------------------
> > >> > To unsubscribe, e-mail: [hidden email]
> > >> > For additional commands, e-mail: [hidden email]
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> The next time you hear: "Don't reinvent the wheel!"
> > >>
> > >>
> > >>
> >
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [hidden email]
> > >> For additional commands, e-mail: [hidden email]
> > >>
> > >>
> >
> >
> >
> > --
> > The next time you hear: "Don't reinvent the wheel!"
> >
> >
> >
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [collection][security] InvokerTransformer missused in java object serialisation exploits

Emmanuel Bourg-3
In reply to this post by Thomas Neidhart
Le 08/11/2015 15:12, Thomas Neidhart a écrit :

> with the default being: do not de-serialize InvokerTransformer?
> Then I would be ok going that route.

I like the idea too. I have a question though: do we use a common
property enabling unsafe deserialization for all commons components, or
do we use a property per component or even per class?

Emmanuel Bourg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collection][security] InvokerTransformer missused in java object serialisation exploits

James Carman
Couldn't they use the same attack vector to set a system property also? I
do believe that would be possible

On Sun, Nov 8, 2015 at 1:46 PM Emmanuel Bourg <[hidden email]> wrote:

> Le 08/11/2015 15:12, Thomas Neidhart a écrit :
>
> > with the default being: do not de-serialize InvokerTransformer?
> > Then I would be ok going that route.
>
> I like the idea too. I have a question though: do we use a common
> property enabling unsafe deserialization for all commons components, or
> do we use a property per component or even per class?
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [collection][security] InvokerTransformer missused in java object serialisation exploits

Thomas Neidhart
On 11/08/2015 07:51 PM, James Carman wrote:
> Couldn't they use the same attack vector to set a system property also? I
> do believe that would be possible

for this you need a way to execute code via a de-serialized class.
Right now, the simplest way to do so is via the InvokerTransformer.

There are surely other ways to do so, but if the only available way is
blocked (i.e. InvokerTransformer can not be deserialized), a remote
attacker cannot set a system property via this attack vector.

btw. setting a system property can also be restricted by a SecurityManager.

I am -1 on a programmatic interface, and for the 4.X branch I propose to
remove the serialization support completely.

Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [collection][security] InvokerTransformer missused in java object serialisation exploits

James Carman
System.setProperty()


On Sun, Nov 8, 2015 at 2:10 PM Thomas Neidhart <[hidden email]>
wrote:

> On 11/08/2015 07:51 PM, James Carman wrote:
> > Couldn't they use the same attack vector to set a system property also? I
> > do believe that would be possible
>
> for this you need a way to execute code via a de-serialized class.
> Right now, the simplest way to do so is via the InvokerTransformer.
>
> There are surely other ways to do so, but if the only available way is
> blocked (i.e. InvokerTransformer can not be deserialized), a remote
> attacker cannot set a system property via this attack vector.
>
> btw. setting a system property can also be restricted by a SecurityManager.
>
> I am -1 on a programmatic interface, and for the 4.X branch I propose to
> remove the serialization support completely.
>
> Thomas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
12