Vulnerability In Java Commons Library Leads To Hundreds of Insecure Applications (foxglovesecurity.com)

An anonymous reader writes: Stephen Breen from the FoxGlove Security team is calling attention to what he calls the "most underrated, underhyped vulnerability of 2015." It's a remote code execution exploit that affects the latest versions of WebLogic, WebSphere, JBoss, Jenkins, and OpenMMS, and many other pieces of software. How? An extremely common Java library. He says, "No one gave it a fancy name, there were no press releases, nobody called Mandiant to come put out the fires. In fact, even though proof of concept code was released over 9 months ago, none of the products mentioned in the title of the blog post have been patched, along with many more. In fact no patch is available for the Java library containing the vulnerability. In addition to any commercial products that are vulnerable, this also affects many custom applications.

Comments

Too much hype for what it actually is

[Kartu]

Your app needs to be accepting Serialized Java objects as input.
Yay.
Never seen that used in any project I was part of and if that would happen security concerns alarm would ring in pretty much any competent team.

Re:Too much hype for what it actually is

[Anonymous Coward]

Your app needs to be accepting Serialized Java objects as input.

Agreed - this is not a "Java" security vulnerability - this is working as designed. Its the responsibility of the application owner to either:
1) Reject any user input of serialized objects
2) Accept said user input and sanitize it.

The applications they found the exploits against is the more interesting part of the story - as they are not sanitizing said input.

For WebSphere Application Server - it looks like this was fixed back in April - though I'd have to contact IBM to be certain.
http://www-01.ibm.com/support/...

Other vendors I'm not as familiar with - but I would hope took similar actions.

Not a vulnerability in Java Commons Library

[artbristol]

The linked article takes a lot of words to get to the point, which is that "WebLogic, WebSphere, JBoss, Jenkins, and OpenMMS, and many other pieces of software." will deserialize arbitrary user-supplied Java objects. To exploit that, you just provide a serialized class from commons-collections which (by design) executes the class's code during its deserialization process. If your application doesn't whitelist the classes it deserializes from an untrusted user, you deserve everything you get.

Re:Not a vulnerability in Java Commons Library

[mridoni]

Yes, whitelisting will help, but only up to a point: unless you implement some signing mechanism or sanitize your input, there's no way you can be sure that the class com.mynamespace.whatever you're deserializing is actually not harmful, even if it apparently is in the right namespace, and has the correct method signatures.

This is just another example of a useful feature leading to a "broken by design" implementation due to an oversight in planning and coding.

Re:Not a vulnerability in Java Commons Library

[Anonymous Coward]

Ehm, Java serialization doesn't work like that. There is no code going over the wire. Just references to classes that the attacker hopes are already present on your classpath, and the data to fill them with. It happens that some classes that you might already have in your classpath are dangerous when used in this way.

Not a Java, or even a library vulnerability

[kervin]

We were corrected by Mr. Frohoff that said the vulnerability is in how developers treat user-supplied serialized data, and not the library itself.

http://news.softpedia.com/news/the-vulnerability-that-will-rock-the-entire-java-world-495840.shtml

This is an issue with how some users use a 3rd party library Apache Commons Collections. Java doesn't have to be fixed. And Apache Commons-Collection doesn't have to be fixed, except maybe stating the obvious...

Do not deserialize objects with executable code from the internet.

Re:Not a Java, or even a library vulnerability

[cbhacking]

Apache Commons Collections contains an arbitrary shell command injection vulnerability reachable from the readObject function of one of its Serializable classes. Due to the way Java deserialization works, any Serializable class can be specified in a serialized Java object format, and unless there's code filtering the serialized binary data before deserializing it, that's enough to trigger the exploit.

Saying "Do not deserialize objects with executable code from the internet." sounds like a solution, but Java deserialization of objects passed on the wire is everywhere, and often even used pre-auth. Some of these things are management interfaces that definitely shouldn't be exposed to the Internet, but most of them will be exposed to the local network and that's still bad (arbitrary code execution in a server's management interface, callable by anybody who has access to the internal network even if they have no creds).

Fixing Commons Collection so that it can't be used for shell command injection would be a much more proper fix. Deserializing Java objects from the Internet *shouldn't* be dangerous; the simple act of deserializing an object should never inherently by harmful! Remember, the attacker can't force you to call any method of those objects. The attacker can't send objects that you don't already have class definitions for. The attacker can't add functions, or otherwise modify the class definitions. The only thing the attacker can be sure will happen is that the readObjection method - if it exists for the class in question - will execute. That's it. That should *NEVER* be enough to get arbitrary code execution!