Vulnerability In Java Commons Library Leads To Hundreds of Insecure Applications (foxglovesecurity.com) 115
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.
Re: (Score:2)
Re: (Score:1)
https://soylentnews.org [soylentnews.org] is a place the cool kids are trying to build out into something that does the old fun and useful /. stuff. So far, it's tough going. Obviously, the more the merrier. Come over and have an effect on the culture.
Too much hype for what it actually is (Score:5, Informative)
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: (Score:1)
Exactly! He makes it sound like all Java app servers are pwned, but when you read TFA, he attacks managament traffic, like JMX.
Raw object serialized traffic (like RMI) should not be exposed to the outside, that's just asking for troubles.
Re: (Score:3)
Yeah but hyperbole sure helps your security company get more web traffic.
That's the real vulnerability.
Have fun rolling your own Multimap. (Score:2)
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
Actually, a project using commons is questionable right off the bat. The commons libraries have so many problems it's almost always better to avoid them. Commons logging is a travesty that should have been wholesale replaced long ago, yet it is still "current" and even had a relatively recent nonsensical updates that appear not to address some of its core issues. For a nice read [articles.qos.ch] while old, appears to still be the core of commons-loggings problems. You'll note that Craig McClanahan was involved in this, as w
Re:Too much hype for what it actually is (Score:5, Informative)
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/... [ibm.com]
Other vendors I'm not as familiar with - but I would hope took similar actions.
Re:Too much hype for what it actually is (Score:4, Interesting)
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: (Score:2)
Thinking you can take a object as an external input from anything but a trusted source is asking for trouble.
I think you mean to say
Thinking you can take anything as external input from anything but a trusted source is asking for trouble.
Anyone have that XKCD about Bobby Tables handy?
Re: (Score:2)
Is there such a thing as a trusted source?
Re: (Score:1)
More than that, your application has to be accepting not simple data objects, but classes with executable methods and then those need to be executed.
Of-course there are management tools that can do that (likely for bad reasons), but this also requires that the management tools are accessible from the outside and have no security around them.
Not a vulnerability in Java Commons Library (Score:5, Informative)
Re: (Score:2, Informative)
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 (Score:4, Informative)
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: (Score:1)
Yep.
Specifically, somebody at commons collection figured it would be a good idea to have a serializable class that will call through reflection any arbitrary method with any parameters as specified in the deserialized data. Send Runtime.getRuntime().exec(... whatever ...), done.
This is absolutely a problem in commons-collections. This functionality is inherently unsafe, and of use to like 5 people out there, all of which can code the 5 lines required to do this on their own.
The fact that a way was found to
Re: (Score:2)
The type of class loading you are talking about would only happen when using object serialization with RMI and codebase setup to allow for dynamic class downloading. Object serialization only sends the data portion of an object. If you want to know more you can look at how the format works: http://docs.oracle.com/javase/... [oracle.com]
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
In an object oriented language an object is a combination of data and behavior (methods). If you want to transfer data across the wire with an object oriented system the natural place to put that data is into an object. Not trusting object serialization originates from a lack of knowledge on what is happening and you should educate yourself. Everything you want to know about serialization is here: https://docs.oracle.com/javase... [oracle.com]
What you are doing by designing your own data formats is adding inherent white
How to whitelist classes (Score:3)
Here is an example of how to whitelist classes by subclassing ObjectInputStream: http://www.ibm.com/developerwo... [ibm.com]
Re: (Score:2)
And the article is wrong with that.
First of all: serialized objects are only exchanged between servers that agree to that each other. In other words your computer is sending requests to my computer, and I answer only if I know who you are and vice versa.
Serialized objects in Java is no difference than SOAP requests or JSON objects, or CORBA or other means to do RPC/RMI.
In other words: you simply can't attack my App via the web/HTML/Forms just because it is running on a WebSphere EJB Server. No one is going
Re: (Score:1)
Actually, if you'd read the article more carefully, you'd see that it is uploading code. Shell code.
The way it works is this:
When java wants to serialize an annotation, it doesn't actually do that. Annotations are not serializable. Instead it sends a proxy. A specific one called AnnotationInvocationHandler. The purpose of this is to make sure that the downloaded annotation behaves like an annotation (equals, hashcode and so on, for instance it clones array before returning them). This proxy contains a map o
Re: (Score:2)
Finally: serialized objects are just data, they contain no code. So there is nothing to execute. If you read the article, you see: the only code executed is the "readObject" method that already is on the server!!
Did YOU read the article? The serialized objects are just data - well except if someone made a readObject that as part of the deserialization process executes steps based on that data. Programs are just data.
The "bug" is that someone did exactly that and put it into a very common library. If you have that library on your classpath, and chances are very high that you do, then you have no defense against this. You lose the moment you try to deserialize the data. It does not matter that you are expecting the d
Re: (Score:2)
Did YOU read the article? The serialized objects are just data - well except if someone made a readObject that as part of the deserialization process executes steps based on that data. Programs are just data.
Did you read my post?
That readObject method is not in the serialized objects: it needs to be already on the server!
There is no way to smuggle code via deserialization into the computer that is accepting the objects except the way I sketched in my post.
Re: (Score:2)
readObject is not something on the server, it is just a method signature defined by the serializable interface in the Java standard. The vulnerable code needs to be on the server of course, or there is nothing to abuse. The vulnerable code is in the Apache commons library, which has a class that implements serializable and therefore provides a readObject method, that can be abused.
But then you write something like "Serialized objects in Java is no difference than SOAP requests or JSON objects, or CORBA or o
Re: (Score:2)
I stand corrected.
I read the slides mentioned in the article, they are much easier to understand than the article itself, and I have to admit, I stopped reading the first time shortly afte the authors catchy claims: ... ... and does nothing the programmer did not program.
"Java loves to
serialize objects in HTTP requests etc.
"
When Java actually is just a language and a platform
Anyway, we three things:
a) the vulnarability is imho not a vulnarability but a deliberately crafted backdoor. If the author can be fou
Re: Not a vulnerability in Java Commons Library (Score:2)
This! Plus:
Java is perceived to be more vulnerable for the same reason it is more popular ... More comes "in the box."
The Java language comes pre-packaged with a huge set of libraries. C and C++ are really nothing more than concepts. You install a compiler that implements the concept. So, if the compiler has a vulnerability or bug, people blame it on the compiler. Libraries, toolkits, and frameworks are available for C and C++. However, they too are perceived as separate from the languages. So, if said "acc
"Monkey Island" - Now it has a name! (Score:2)
Can you deal with the details, now ?
Because it has gotten a name.
Or is "Bad Coffee" better?
remote code execution expoit, but (Score:1)
Re: (Score:2)
Well, nobody really exposes mentioned software to the internet, right?
For instance, It is accepted as good practice to have nginx used a request router, which kinda lowers the impact of this exploit, or am I am wrong?
'remote' doesn't just mean 'the internet' it can also mean 'local network'.
Not a Java, or even a library vulnerability (Score:4, Informative)
http://news.softpedia.com/news/the-vulnerability-that-will-rock-the-entire-java-world-495840.shtml [softpedia.com]
This is an issue with how some users use a 3rd party library Apache Commons Collections [apache.org]. 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: (Score:2)
There's a warning right there in the org.apache.commons.collections.Limb.Foot documentation about calling the doShoot() method with unsigned copies of org.apache.http.client.Bullet.
Re:Not a Java, or even a library vulnerability (Score:4, Informative)
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!
Re: (Score:2)
Re: (Score:1)
Would it kill you to mention the vulnerability? (Score:3)
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.]]
Re: (Score:2)
apps blindly trust network input and let it run in their execution context
If you put it that way, you've basically described every remote execution exploit. You ought to mention that it's in the de-serialization library (although the writers of the library would say, "you're holding it wrong").
Re: (Score:2)
It's an OS commend injection vulnerability. Deserializing an object should not, by itself, ever execute arbitrary code. The only function that automatically runs on a deserialized object is that object's readObject function, which should in no way be usable to execute an arbitrary OS command. Apparently the writers of this library would find that concept bemusing.
This isn't a matter of
Thi
Re: (Score:2)
Deserializing an object should not, by itself, ever execute arbitrary code. The only function that automatically runs on a deserialized object is that object's readObject function, which should in no way be usable to execute an arbitrary OS command.
Yeah, allowing arbitrary OS commands to be executed during deserialization violates the principle of least astonishment.
apache commons (Score:1)
Re: (Score:1)
Sure, but the list of affected web apps is impressive.
WebLogic, WebSphere, JBoss, Jenkins, OpenNMS
The trouble comes from the fact that it looks like using any part of the Commons libs will pull in this vulnerability and the Apache devs are basically saying "don't allow serialised object to come in from the network." but that seriously hinders the usability of a web app.
And as others have pointed out, if you use a serialized object in the cookies - say a state cookie - the vulnerability can be invoked before the user input is touched.
Apache Commons Collections 3.x. (Score:2)
It was pretty darn hard to parse that article to understand what library the author was talking about, but after some research, the issue seems to be a vulnerability in the Apache Commons Collections [apache.org] library.
I don't understand why the OP calls it "Java commons" or why the author of the article goes out of his way to not mention the name "Apache", using it only when copying and pasting code lines but never stating it in prose. Sure, there are lots of people who may have Java, but if the security vulnerabili
Re: (Score:1)
I don't understand why the OP calls it "Java commons"...
Probably because the path where the web applications keep the jar file is .../WEB-INF/lib/commons-collections-3.2.1.jar. No mention of Apache in that path.
CVE number? (Score:1)
Looking in the wrong place. (Score:1)
The real fault seems to be in classes like AnnotationInvocationHandler or PriorityQueue (both part of the Java library), whose readObject() methods trustingly call some methods on their child objects.
AnnotationInvocationHandler calls map.entrySet(); PriorityQueue calls compare(). You just make sure the child object executes malicious code when executing those methods. For the child object, you can find a utility class such as LazyMap (from Commons) that executes a function while calling entrySet(). Th
Re: (Score:1)
Magnitudes slower means "10-100-1000 times slower" which is BS.
Java's main problem is memory footprint, not execution speed.
Which is on par with C++ code, unless you do extreme object allocate/GC or use sin/cos (which used to be done NOT using CPUs capabilities, leading to much slower code. All to guarantee exactly the same result across platforms)
Re: (Score:2)
There are so many scenarios, some where Java is faster than C++ and somewhere it is slower.
To make some kind of blanket statement makes you look like a moron.
Re: (Score:1)
That sounds like a blanket statement to me...
Re: Another example of why Java sucks (Score:1)
That's because you apparently can't follow a conversation.
Re: (Score:1)
Re: (Score:1)
I don't know "so many" but multiple small allocations/deallocations is one example.
Each new/delete is a rather complex system call, no matter how little you allocate. In case of Java it allocates quite efficiently from its internal reserve (which isn't that much of an improvement, but still some) and performs bulk GC instead of deallocating each item separately (which is a big improvement).
Garbage Collector in a lot of cases is a liability, especially if it obscures memory leaks and introduces hiccups in sy
Re: Another example of why Java sucks (Score:2)
C++ applications can and do use GC just like Java does. The difference is you can choose how you manage memory.
Your post doesn't really make much sense.
Re: (Score:1)
new and delete don't generally make system calls. The system call is brk(), and it's only needed to resize the heap. The C and C++ runtimes also allocate a large heap at startup, and will only resize it when it approaches exhaustion.
Basically, the entire point of your post is lost because it is based on a misunderstanding.
Re: (Score:1)
Re: (Score:2)
Re: Another example of why Java sucks (Score:2)
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.
Re: (Score:2)
If you are so enlightened why are you spending your Saturday night criticizing strangers over the Internet when you could be biting your nails in fear of ISIS? Clearly reckless panic will be effective, so lead by example!
Re: (Score:2)
Thanks to this bug I can see a whole bunch of you masturbating in front of your tablets right now!
That would definitely be a bug, not a feature.
Re: (Score:1)