camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ed Welch">
Subject Re: CVE-2015-5348 - Apache Camel medium disclosure vulnerability
Date Thu, 17 Dec 2015 20:43:22 GMT
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:

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:

                .process(exchange -> {
          "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

Looked in /tmp, no file! hooray?

maybe not yet, looked at the logs, see:

Caused by: java.lang.ClassNotFoundException:

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:,

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

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

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...


On Thu, 17 Dec 2015 10:27:59 +0100, Claus Ibsen <> 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]
> [2]
> On behalf of the Camel PMC,
> Claus Ibsen
> -- 
> Claus Ibsen
> -----------------
> @davsclaus
> Camel in Action 2:

View raw message