Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Java Security Software

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.
This discussion has been archived. No new comments can be posted.

Vulnerability In Java Commons Library Leads To Hundreds of Insecure Applications

Comments Filter:
  • by Kartu ( 1490911 ) on Sunday November 08, 2015 @06:04AM (#50887057)

    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.

    • by Anonymous Coward

      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.

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

        That's the real vulnerability.

    • by Anonymous Coward on Sunday November 08, 2015 @06:55AM (#50887131)

      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.

      • by DarkOx ( 621550 ) on Sunday November 08, 2015 @08:18AM (#50887279) Journal

        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.

        • 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?

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

  • by artbristol ( 904315 ) on Sunday November 08, 2015 @06:26AM (#50887079)
    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: (Score:2, Informative)

      by mridoni ( 228377 )

      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.

      • by Anonymous Coward on Sunday November 08, 2015 @08:35AM (#50887325)

        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.

        • by Anonymous Coward

          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

      • 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]

      • Once, just once I would like to see somebody here discuss Java that actually knows how the fuck it works.
    • If your application doesn't whitelist the classes it deserializes from an untrusted user, you deserve everything you get.

      Define you and your here! How many people do you think will be hit by this who had any role whatsoever in the development or design of the standard install of the application concerned.

      I think there's a lot to be concerned about here. At the very least:

      - It should be easier to update a single library for a range of Java applications
      - It should be easier to distribute security upda

      • 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

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

    • 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

      • by Anonymous Coward

        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

      • by bbn ( 172659 )

        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

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

          • by bbn ( 172659 )

            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

            • 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:
              "Java loves to ...
              serialize objects in HTTP requests etc.
              "
              When Java actually is just a language and a platform ... and does nothing the programmer did not program.

              Anyway, we three things:
              a) the vulnarability is imho not a vulnarability but a deliberately crafted backdoor. If the author can be fou

    • 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

  • Can you deal with the details, now ?

    Because it has gotten a name.

    Or is "Bad Coffee" better?

  • 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?
    • 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'.

  • by kervin ( 64171 ) on Sunday November 08, 2015 @09:01AM (#50887397) Homepage

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

    • by PPH ( 736903 )

      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.

    • 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!

  • by shess ( 31691 ) on Sunday November 08, 2015 @10:19AM (#50887679) Homepage

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

    • 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").

      • 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

        Deserialize the object, see if it's an instance of FootGun, and if so call its shoot() function. We're just that stupid.

        Thi

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

  • "Commons"? Fortunately, not universal. Naming a library "commons" does not make it part of the language. All those Apache Commons libraries share one thing: they are mostly collections of anti-patterns. Stuff that can often be done better without dependencies, with real standard libraries (part of the platform) instead of collections of trees of mutually-incompatible libraries that look as written by a lazy first-year student. They feature null checks that make it obvious that the lazy programmer that use t
    • 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.

  • 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

    • 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 or it didn't happen. https://en.wikipedia.org/wiki/... [wikipedia.org]
  • 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

"I never let my schooling get in the way of my education." -- Mark Twain

Working...