Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by Soulskill on from the devil-is-in-the-dependencies dept.

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.

61 of 115 comments (clear)

  1. Re:Another example of why Java sucks by Kartu · · 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)

  2. Too much hype for what it actually is by Kartu · · 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.

    1. Re:Too much hype for what it actually is by Anonymous Coward · · 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.

    2. Re:Too much hype for what it actually is by Anonymous Coward · · 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/...

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

    3. Re:Too much hype for what it actually is by DarkOx · · Score: 3, 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.

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    4. Re:Too much hype for what it actually is by binarylarry · · Score: 2

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

      That's the real vulnerability.

      --
      Mod me down, my New Earth Global Warmingist friends!
    5. Re:Too much hype for what it actually is by roman_mir · · 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.

      --
      You can't handle the truth.
    6. Re:Too much hype for what it actually is by i.r.id10t · · Score: 1

      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?

      --
      Don't blame me, I voted for Kodos
    7. Re:Too much hype for what it actually is by GodelEscherBlecch · · Score: 1

      So let me get this straight: You ban commons. You copy what you were using from commons into your own codebase (hint: this also was all you were using of commons it when you still had it). To hold to your insane 'not invented here' paranoia, you must also have banned all other projects that use commons as a dependency. So, you copy from those projects what you use, then make it use your own 'commons', or maybe you re-implement them wholesale. You rest assured in the knowledge that nasty commons code which you were not invoking will not wake up and start doing evil things all on its own, and that all of the wonderful proprietary wheels which you have re-invented are all sure to be 100% vulnerability-free because you wrote them. ??? Profit You are a genius.

    8. Re:Too much hype for what it actually is by Gr8Apes · · 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 while old, appears to still be the core of commons-loggings problems. You'll note that Craig McClanahan was involved in this, as with Digester, another pile of pain if you want to do anything dynamic. In fact, I'd go out on a limb and state that everything Craig did works statically only, if you're doing any long-running systems with mutations, you'll be debugging and altering anything he wrote (I've been through Tomcat, JBoss's adaptation of Tomcat's core, Struts, Commons-Digester and Commons-Logging among other libraries, so yes, I do indeed know what smells under the covers regarding his work)

      Considering the bugs in those libraries, I'm pretty sure proprietary code is not any worse given my own history.

      --
      The cesspool just got a check and balance.
    9. Re:Too much hype for what it actually is by Richard_at_work · · Score: 1

      Is there such a thing as a trusted source?

  3. Not a vulnerability in Java Commons Library by artbristol · · Score: 5, Informative

    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.

    1. Re:Not a vulnerability in Java Commons Library by mridoni · · 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.

    2. Re:Not a vulnerability in Java Commons Library by squiggleslash · · Score: 1

      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 updates for Java applications and libraries
      - Java's serialization scheme, in assuming that anything in the classpath would constitute a valid object to be deserialized, needs some rethinking.

      I'm curious to know whether many/any other languages are in a similar situation. I've certainly seen some cryptic crap in the past generated by PHP that's supposed to be an implementation of something similar, but never investigated it in detail. It might be done right, which would be a miracle if it's PHP...

      I'll be honest, I never fully trusted Java's serialization and always chose to design output formats instead. A lot of developer co-workers felt I was creating work for myself, and my main motivation was to have a format I (and others) could understand and debug, but - hey, understanding is half the security battle.

      --
      You are not alone. This is not normal. None of this is normal.
    3. Re:Not a vulnerability in Java Commons Library by Anonymous Coward · · 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.

    4. Re:Not a vulnerability in Java Commons Library by Anonymous Coward · · 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 trigger this during deserialization itself, instead of triggered by a method call later, is just icing on the cake.

    5. Re:Not a vulnerability in Java Commons Library by ChaseTec · · Score: 1

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

      --
      My Hello World is 512 bytes. But it's also a valid Fat12 boot sector, Fat12 file reader, and Pmode routine.
    6. Re:Not a vulnerability in Java Commons Library by ChaseTec · · Score: 1

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

      What you are doing by designing your own data formats is adding inherent whitelisting. Your reader/parser probably does a "new" on a specific set of classes. That prevents the type of vulnerability (arbitrary class loading) being discussed in the article but also requires you to reinvent the wheel for every data format.

      You could have been using http://docs.oracle.com/javase/... to serialize data since that would give you an easy way to inspect the data type before recreating. You can even setup inspection/whitelisting with traditional object serialization if you wanted to: http://www.ibm.com/developerwo... .

      Nowadays JSON is a pretty universal data format for wire transfers. You can deserialize JSON to trusted data-centric classes like Map, List, String, Integer, etc. That would give you universal encoding/decoding without arbitrary class loading. Unless you are required by a 2nd party to use some proprietary wire format there is no reason to roll-your-own encoding/decoding.

      --
      My Hello World is 512 bytes. But it's also a valid Fat12 boot sector, Fat12 file reader, and Pmode routine.
    7. Re:Not a vulnerability in Java Commons Library by angel'o'sphere · · Score: 1

      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 to input a serialized object into a random field in a web form and the server is "executing" it.

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

      Could you craft such an exploit to actually do exploit something? Yes, if the host in question trusts you, AND if you know a good deal about the software running there.

      First of all: there is no outside code executed when you transfer an object, the article is wrong with that. So you need a way to execute your code. The only way I can imagine is: you provide objects of derived classes. E.g. if on the server a class "Customer" exists and you are regularly sending serialized objects of that type to the server, you could send a "DerivedCustomer" object, because only then the server would hick up and say: no idea how to deserialize that! I have no class called "DerivedCustomer" and the server tries to download that one from you, with a so called RemoteClass loader. Now if you have some rogue code in a simple method like "getCustomerID()" of course you can execute that.

      However, as I explained in the beginning ... somehow you have to convince the server and its owner to load serialized objects from you: how do you do that?

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    8. Re:Not a vulnerability in Java Commons Library by Anonymous Coward · · 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 of the annotation's values. During deserialization Java checks that the values in this map are of the right type. To do this, it needs to get them.

      Enters commons-collection. This contains a specialized map that allows values to be lazily created or modified as required, using the Transformer interface. Fine.

      The problem is that someone thought it would be a good idea to have a transform that:
      a) is serializable;
      b) calls arbitrary code using reflection based on the serialised strings!

      What the exploit does is pass in a AnnotationInvocationHandler that contains a crafted commons-collection map that contains a few chained InvokationTransformer that in effect invoke Runtime.getRuntime().exec(shellcode). "java.lang.Runtime", "getRuntime()", "exec" and "shellcode" all being serialized parameters.

      Game over.

      One could argue that the AnnotationInvocationHandler should maybe vet the Map type.
      One could also argue for whitelisting - except usually people drag in commons-collections because they want to use these collections.
      But fundamentally, the problem is with this InvokationTransformer. There's no good reason to have a class running reflection from deserialised state. That's just asking for trouble.

      As for convincing the server to accept them, well, that's fair enough. The problem is that quite a few of those servers will by default accept RMI connections, sometimes over the internet, for management purposes.

    9. Re:Not a vulnerability in Java Commons Library by bbn · · Score: 1

      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 data to deserialize to something completely different.

      Say you make a class called UserInfo and put that into a cookie using serialization. If you did that, you are a goner. There is no way you can deserialize that cookie without risking that somebody replaced the cookie value with serialized data from Apache commons. You will not know that it is not actually UserInfo data anymore until after he rooted your system.

      The only solution is to a) do not deserialize data that could be modified by an adversary. Or b) if you must, make sure Apache commons is not on the classpath while you do so (could be done with a custom classloader).

      Personally I would ditch the build in java serialization and use another serialization library, one which does not allow arbitrary class names in the serialization data. I switched to Scala long ago and in the Scala world most serialization libraries do not use reflection to (de)serialize, and therefore fulfill that requirement.

    10. Re: Not a vulnerability in Java Commons Library by GrantRobertson · · Score: 1

      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 "accessories' have bugs, people blame it on the accessories rather than the language.

      C and C++, by definition, cannot have bugs because the are merely concepts. "Java," by its definition as a concept as well as an entire ecosystem of actual code is bound to have infinitely more bugs than C or C++.

      When people blame the Java concept and ecosystem as a whole for bugs that exist in one or two of said "accessories," it just shows me they haven't learned how to use that wet, squishy thing just below their hair-product display area.

    11. Re:Not a vulnerability in Java Commons Library by angel'o'sphere · · Score: 1

      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.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
    12. Re:Not a vulnerability in Java Commons Library by bbn · · Score: 1

      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 other means to do RPC/RMI". But that is completely wrong in this context. The reason we have this bug is exactly because there is a difference from java serialization and all of the others that you mention. And that difference is that the serialization data includes arbitrary class names that allows the attacker to cause your code to load _any_ class that implements the serializable interface, no matter if that has anything to do with what you are working with here or not.

      If you use JSON you will not have that. JSON can only cause strings, numbers, arrays and hashmaps to load.

      This is also wrong: "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!!" - yes the exploit is in a readObject implementation, but that exploit allows the attacker to transmit arbitrary code and have it executed. Code that was in no way on the server already.

      "First of all: there is no outside code executed when you transfer an object, the article is wrong with that. So you need a way to execute your code. The only way I can imagine is" - or the way the article describes. Which is not a derived object. He sends a serialization of a completely different object, namely the vulnerable class in Apache commons. The deserialization in Java just returns "Object" - there is no expectation here that the returned object be of the type that you, the programmer, expects. You will then of course get a class cast exception if you just cast it, or your code will notice something is not right if you do a isInstanceOf on it. But by then it is too late, he already had his custom code executed by Apache commons when the readObject method in there was called.

      You need to know absolutely nothing about the system you want to attack. You only need two things, one is for the system to be vulnerable (=Apache commons needs to be on the classpath) and the other is that you need to find something the system serializes. You do not need to care about what it is that it serializes, because you will provide it with your hacked object, and the deserialization will fail but by then you already got what you want.

      So if your web application does not use serialization the second prerequisite will fail and you are safe. But if you did something like putting a serialized object into a cookie, then you are done for.

    13. Re:Not a vulnerability in Java Commons Library by GodelEscherBlecch · · Score: 1

      Once, just once I would like to see somebody here discuss Java that actually knows how the fuck it works.

    14. Re:Not a vulnerability in Java Commons Library by angel'o'sphere · · Score: 1

      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 found via the SCCS, he should minimum ne banned from contributing or even criminal prosecuted
      b) my thought process, even under the knowledge that there is a flaw in the commons lib, was wrong. First of all I never came to the idea that one indeed would serialize objectes into cookies or do similar nonsense with them. See c)
      c) I was more thinking about RMI, where I basically call a method like:

            remoteEndpoint.myMethod(new MyPayloadClass(), some, other, args);

      As the method signature is defined in the remote interface of the server, my thought process was: the server will reject the payload if it is of the wrong tyoe and throws an RemoteException.
      Problem: the call and/or the exception happens after the deserialization. So the bad code in apache commons already is executed. Or perhaps easier explained: such a remote call works basically in the following steps
      1) a normal method call to a stub method on the client side
      2) the RMI/serialization framework serializes the parameters and the name of the interface and the name of the method to call into a 'blob'
      3) that blob is send via the network
      4) now the harm begins: before being able to to know if the recieved data matches the interface, it needs to be deserialized. If an attacker sends instead of MyPayloadClass and EvilCommonsObject, the deserialization will execute what ever commands are hidden inside EvilCommonsObject
      5) the remote call is deserialized, the RMI framework now can deside which method to call, if it exists and if the parameters match, the call is either executed and its result or exceptions are send back, or the call is rejected with an exception.
      As we see, the harm was in step 4) and the attacker would not care about step 5) anyway.

      Thanx for persisting on the topic. Someone never stops learning new tricks/pitfalls.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  4. Re:ISIS is bombing passenger planes by MobileTatsu-NJG · · Score: 1

    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!

    --

    "I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)

  5. Re: Another example of why Java sucks by Anonymous Coward · · 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.

  6. "Monkey Island" - Now it has a name! by burni2 · · Score: 1

    Can you deal with the details, now ?

    Because it has gotten a name.

    Or is "Bad Coffee" better?

  7. remote code execution expoit, but by nmpg · · Score: 1

    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?

    1. Re:remote code execution expoit, but by myowntrueself · · Score: 1

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

      --
      In the free world the media isn't government run; the government is media run.
  8. Re:Another example of why Java sucks by binarylarry · · Score: 1

    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.

    --
    Mod me down, my New Earth Global Warmingist friends!
  9. Not a Java, or even a library vulnerability by kervin · · Score: 3, Informative

    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.

    1. Re:Not a Java, or even a library vulnerability by PPH · · Score: 1

      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.

      --
      Have gnu, will travel.
    2. Re:Not a Java, or even a library vulnerability by cbhacking · · Score: 3, 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!

      --
      There's no place I could be, since I've found Serenity...
  10. Re:Another example of why Java sucks by Anonymous Coward · · Score: 1

    There are so many scenarios, some where Java is faster than C++ and somewhere it is slower.

    That sounds like a blanket statement to me...

  11. Re:Another example of why Java sucks by Anonymous Coward · · 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 systems that should behave smoothly (multimedia/games). But in this particular scenario it outperforms multiple manual deallocations by strides.

  12. Re:Another example of why Java sucks by God+of+Lemmings · · Score: 1

    C++ maybe, but never C. Its simply not possible.

    --
    Non sequitur: Your facts are uncoordinated.
  13. Would it kill you to mention the vulnerability? by shess · · Score: 2

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

    1. Re:Would it kill you to mention the vulnerability? by phantomfive · · Score: 1

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

      --
      "First they came for the slanderers and i said nothing."
    2. Re:Would it kill you to mention the vulnerability? by cbhacking · · Score: 1

      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.

      This is more a matter of

      Well, we expect an object of type Foo, but it should matter what it is as long as we don't call any functions on it and it can only be something in our server's classpath anyhow. Let's deserialize it to see what it is. Huh, it deserialized to a FootGun instead, and for some reason the FootGun class automatically calls shoot() upon deserialization!
       
        Why the fuck do we even have a self-firing FootGun in our classpath, anyhow?

      In case you missed it, the Apache Commons Collection library is, for some reason, shipping a self-firing footgun. They should patch that.

      --
      There's no place I could be, since I've found Serenity...
    3. Re:Would it kill you to mention the vulnerability? by phantomfive · · Score: 1

      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.

      --
      "First they came for the slanderers and i said nothing."
  14. Re:Dead language. by Ash-Fox · · Score: 1

    It's not an Oracle issue though, it's how developers are using a 3rd party library.

    --
    Change is certain; progress is not obligatory.
  15. Re:YEAH by ColdWetDog · · Score: 1

    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.

    --
    Faster! Faster! Faster would be better!
  16. Re:OK by jones_supa · · Score: 1

    Then can you show an example of some past Slashdot article and its comments that you saw being high quality?

  17. How to whitelist classes by ChaseTec · · Score: 2

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

    --
    My Hello World is 512 bytes. But it's also a valid Fat12 boot sector, Fat12 file reader, and Pmode routine.
  18. Re: Another example of why Java sucks by binarylarry · · Score: 1

    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.

    --
    Mod me down, my New Earth Global Warmingist friends!
  19. apache commons by melmut · · Score: 1

    "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 them consider null and empty as equivalent, which should in itself raise red lights. At best, they reinvent the wheel, quite often in a bad way. Those dependencies are something you won't find in my projects, and the first thing I remove from projects that I have to take over. Whoever depends on this deserved those things. I'd need to read TFA more extensively, but is there any bug report open for the concerned app servers?

    1. Re:apache commons by prunus.avium · · 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.

  20. Have fun rolling your own Multimap. by Rujiel · · Score: 1

    There are a lot of reasons to use apache commons beyond checking if a string is empty.

    1. Re:Have fun rolling your own Multimap. by Gr8Apes · · Score: 1

      And there are a lot more reasons to avoid including them.

      --
      The cesspool just got a check and balance.
  21. Apache Commons Collections 3.x. by Corporate+T00l · · Score: 1

    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 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 vulnerability is of the magnitude that is claimed, properly identifying where it is located would be the logical first step.

    There is a somewhat better article at InfoQ.com that parses out the original article and describes it more clearly.

    1. Re:Apache Commons Collections 3.x. by prunus.avium · · 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.

  22. Re:Another example of why Java sucks by vipw · · 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.

  23. CVE number? by KlaatuVarataNiktu · · Score: 1

    CVE number or it didn't happen. https://en.wikipedia.org/wiki/...

  24. Re:Another example of why Java sucks by GodelEscherBlecch · · Score: 1

    I am almost impressed at your epic failure of both reading comprehension and logic. Also, who the hell chooses Java for speed? Java has benefits and detriments. If you think you can say C++ > Java just because you wrote some big loopy tests, you are even dumber than your above statement makes you look.

  25. Re:Another example of why Java sucks by GodelEscherBlecch · · Score: 1

    The garbage collector only obscures memory leaks if you look for them in the wrong place. If you actually took the time to learn how something works before dismissing it, you might find that profiling the JVM heap and backtracking excessive object allocations / orphanings is about the easiest problem one can detect / solve in a Java application. And who the hell is using Java for gaming/multimedia? No wonder you disliked the screwdriver with which you attempted to hammer a nail. I might as well say that C++ is shit because it takes too long to build a web UI or implement an enterprise BPM engine.

  26. Re:Dead language. by GodelEscherBlecch · · Score: 1

    Holy shit. Do you actually think that this has anything to do with the Java that is installed on your computer? To be safe, better go ahead and delete that OS too!

  27. Re:Not a big JAVA fan here but... apk by GodelEscherBlecch · · Score: 1

    No, you must not be a big Java fan (or person who is the least bit aware of how it works or what it is good for). You do realize that it is not the language that would be patched but a commonly used open source project, right? And that such projects can be written in any language to have vulnerabilities? Hmm...how many vulnerability-inducing DLLs/SOs have ever been created vs .jars? Which one is more likely to allow arbitrary code execution vs. just offering somebody the ability to destabilize the application itself? Yeah, we really need to 'patch' that Java menace. And, to do a compare/contrast of Java / C++ based on syntax and the basics of object allocation just severely misses the point of why you would use one or the other.

  28. Re:OK by obscuro · · Score: 1

    https://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.

    --
    Every rule has more than one consequence.
  29. Looking in the wrong place. by purplie · · 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(). The function can be another utility class that executes some method by reflection (e.g. a Runtime method). These utility classes are all over the place to support functional-style or config-as-code programming.

    But I think the real fault lies in those classes that execute child code during readObject(). It doesn't lie in the Commons classes that are used for the children.