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.

Re:Too much hype for what it actually is

[DarkOx]

2) Accept said user input and sanitize it.

Good luck with that! its like accepting user input that you are going to insert into a javascript string to write back to the client in a web application. No matter what you have done to sanitize it there is still almost always a hole. You just can't safely inject user controlled content into an interpreter or execution context, less the syntax is really well defined and limited. Consider SQL injection, SQL syntax and grammar is pretty specific yet it too 10 years before functions like 'escapestrings' became dependable in major frameworks and everyone had rightly moved on to tools like parametrized queries or solutions like linq by then.

Thinking you can take a object as an external input from anything but a trusted source is asking for trouble. If you do trust the source than the input domain is probably limited to begin with and there is almost certainly a better way.

Re:Too much hype for what it actually is

[binarylarry]

Yeah but hyperbole sure helps your security company get more web traffic.

That's the real vulnerability.

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.

Re: Another example of why Java sucks

[Anonymous Coward]

Comparing C++ and Java is like comparing Assembler and C++. Why dont you use assembler over C++? Same reason why ppl use Java over C++. Plus it depends on what you are developing. C# vs Java thats different story but C# has similar up and downs as Java. So this discussion is kinda pointless.

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!

Would it kill you to mention the vulnerability?

[shess]

Is it so subtle and insidious that it is simply impossible to name? Or do you just not understand what you're reading?

[Here, let me give it a go: Basically apps blindly trust network input and let it run in their execution context.]

[[Though I suppose when you put it _that_ way, you can't spend your time implying that it's somehow Java's fault.]]

How to whitelist classes

[ChaseTec]

Here is an example of how to whitelist classes by subclassing ObjectInputStream: http://www.ibm.com/developerwo...