back to article Whisper this, but Java deserialisation vulnerability affects more libraries

A Java deserialisation vulnerability may affect as many as 40 more software libraries than first feared, research has revealed this week. The deserialisation bug in Apache Commons Collections affects popular distributed software such as WebSphere and JBoss, FoxGlove Security advised last month. But new research by security- …

  1. the spectacularly refined chap

    Misses the point of serialisation...

    ...namely, a convenient and efficient method of dumping objects. Once you spend too much time and effort validating what you read back it loses that advantage. It's probably much safer to derive a traditional file format instead: the constraints of such a format naturally restrict what you can do compared to a serialised object.

    Not that this really strikes me as an issue with serialisation per se but inappropriate usage. In the context of a trusted store there is no issue, it is only when external data is introduced this becomes a risk. Not doing the checks on import is the real vulnerability, not with deserialisation itself.

    1. James 47

      Re: Misses the point of serialisation...

      What are you banging on about? Are you saying that traditional file format do not require validation? You're totally wrong if you are.

      1. Brewster's Angle Grinder Silver badge

        Re: Misses the point of serialisation...

        @James47

        What he said is that once you start validating de-serialized data, its about as efficient as loading a traditional file format. (I tend to agree.)

    2. Vincent Ballard

      Re: Misses the point of serialisation...

      The other problem is that the support for validating your data stream before deserialising is negligible to non-existent. A nice compromise between writing a custom file format and using insecure serialisation would be to allow deserialisation with a custom "context" object which allows you to filter the classes which may be deserialised. If I can permit deserialising anything whose package begins com.mycompany. and reject anything else then I'm safe from whatever weirdness org.apache might have in its many libraries.

      1. dajames Silver badge

        Re: Misses the point of serialisation...

        If I can permit deserialising anything whose package begins com.mycompany. and reject anything else then I'm safe from whatever weirdness org.apache might have in its many libraries.

        The issue here is exploits that rely on deserialization code mis-handling data that have been specially crafted to cause a security breach. An attacker using such a technique can easily put "com.mycompany" into the crafted packet if that's all you check.

        1. Vincent Ballard

          Re: Misses the point of serialisation...

          Specifically, it's about deserialising classes from org.apache which use a deserialisation hook to parse their embedded data and execute a process defined by such data. This exploit would not be possible if attackers could only craft packets containing classes which I've written and which don't do such crazy things. (Of course, that doesn't mean that there couldn't be any vulnerabilities, but they would be more specific).

    3. Steve Channell
      Facepalm

      Misunderstanding serialisation

      Pretending that a defect is a feature by redefining “serialisation” doesn’t help any more than saying RMI was “designed” to execute sh1t on a remote computer… it was designed to work in a fully trusted environment, which doesn’t apply in many cases where it is used. ASP.NET had the same vulnerability with viewstate (until it was fixed with encryption).

      The problem here is not ‘validation’ RMI validates data to guard against corruption in transit, the issue is dynamic deserialization where you get to provide your own bytecode for the object and in-principle the same as SQL injection. The fix is in-principle the same as SQL-Injection: re-code your application to be secure

  2. Jan 0 Silver badge

    This article needs padding!

    This article is ridiculously short. How about padding it out with a useful guide to deserialisation?

  3. Chewi
    Linux

    Serves the Java community right

    ...for bundling things all the time. The situation has improved slightly with Maven but end users still tend to get the software handed to them in one fat bundle. There's a reason why Linux distributions do things the hard way.

    Lots of love,

    The reluctant Gentoo Java lead

    1. sabroni Silver badge
      Windows

      Re: end users still tend to get the software handed to them in one fat bundle

      An end user needs a single bundle. You don't buy a car, then go and get an engine, some suspension, some wheels, brakes, an exhaust etc.... End users want a working thing, they don't care that it's made of lots of sub-things.

      1. gerdesj Silver badge
        Childcatcher

        Re: end users still tend to get the software handed to them in one fat bundle

        "An end user needs a single bundle. You don't buy a car, then go and get an engine, some suspension, some wheels, brakes, an exhaust etc.... End users want a working thing, they don't care that it's made of lots of sub-things."

        Car analogies tend to break down pretty quickly these days. I want 20 cars and I want them to only have a different coloured windscreen and different dashboard items. Some of them I want to run on diesel and some on petrol. Some I want to have two seats and some of them I want to have four or maybe eight at times.

        I do not want to have to get three versions of petrol (one of which is four star which I have trouble buying due to the lead content - Java 1.4 or MS Java ... )

        It can be done just but it is tortuous. Why not stick to describing software packaging - they are not cars?

      2. Wommit
        Joke

        Re: end users still tend to get the software handed to them in one fat bundle

        "You don't buy a car, then go and get an engine, some suspension, some wheels, brakes, an exhaust etc"

        Don't you! Bugger, that's where I've been doing it wrong.

      3. Tomato42
        Facepalm

        Re: end users still tend to get the software handed to them in one fat bundle

        @sabroni: yes, but users also expect to be able to change spark plugs and exhaust if it breaks in any garage, and not be required to buy a new car from the same manufacturer to make their trailer still be useful.

    2. gerdesj Silver badge
      Linux

      Re: Serves the Java community right

      "The reluctant Gentoo Java lead"

      @chewi: Thanks for your herd's work. Life with Java in Gentoo is a lot more straight forwards these days.

    3. Anonymous Coward
      Anonymous Coward

      Re: Serves the Java community right

      s/bundling/bungling/

      FTFY

  4. Tom 7 Silver badge

    Internally written?

    My eyes are watering at the idea.

  5. wikkity

    Inventorying which libraries are used by which specific software is notoriously difficult

    No it's not

    mvn dependency:list

  6. wikkity

    The root cause

    "The root cause of the problem is down to apps not validating or checking untrusted input prior to deserialisation"

    I bet c#/c++/ruby/... developers are pleased that this is a java specific problem then.

    Who in their right mind does not validate untrusted input and find it hard to beleive that anyone would de-serialise objects with data from an unknown source or even expose an endpoint that expected it? Probably the same people who concatenate user input string to make sql statements. They deserve what they get.

    1. This post has been deleted by its author

    2. Michael Wojcik Silver badge

      Re: The root cause

      The "in their right mind" is debatable, but take a look at the Foxglove post, which demonstrates the vulnerability in such niche products as WebLogic, Websphere, JBoss, and Jenkins.

      Many, many people deserialize object streams from untrusted sources. It's very common. As the Foxglove analysis shows, often it's wrapped in some proprietary protocol rather than being plain RMI, so an attacker has to spend, oh, several minutes figuring out how to inject the malicious payload.

  7. Christian Berger

    I wonder what sort of mind set is behind this

    I mean seriously, it's _never_ a good idea to store your internal data structures, whether you use simple memory copies or deserialisation methods from your language.

    Even if there were no security problems with this, you'd still make it needlessly hard for someone using a different programming language to interface with your software.

    1. Anonymous Curd

      Re: I wonder what sort of mind set is behind this

      In many areas of the modern Java ecosystem (and others) it's as-good-as standard practice now. Thrift, protobuf and Avro all have as many advantages as on-disk serialised data as they do in memory or over the wire. There's nothing fundamentally wrong with it.

      Storing serialised data is also a red herring. If you read through the (excellent) detailed analysis on FoxGlove you'll see there's a strong focus on attacking over the wire. The obvious reason is because that's way easier to attack than something in memory or on disk.

      The other reasons are also responsible for why this is such an absolute pain in the arse to fix:

      - commons-* cruft is all over the place, despite it being widely acknowledged as Generally Terrible Code

      - It is especially all over the place in big, monolithic enterprise apps

      - These enterprise apps tend not to be the best citizens in terms of general security; for example they might have auth and encryption on your http interface, but leave all the binary management interfaces (speaking their internal protocols only) wide open to anyone.

      - These enterprise apps also tend to (as do most apps, to a lesser extent) bundle up the vulnerable dependency in ways that make it painful to fix. In that foxglove article you'll see the apache commons libraries have been re-namespaced from org.apache.commons.. to com.bea.core.apache.commons. This is an artefact of Java's archaic package management; it's common practise in big apps to just move classes that are likely to clash, giving you total control. This makes them nigh-on impossible to fix. You can't just swap out a jar, you've got to repackage their jar to fix the issue and hope you matched their scheme.

  8. Old Handle
    Facepalm

    Have I got this right?

    This is a new one to me, someone please tell me if I'm understanding this right. Java programs routinely back up objects into binary blobs, fling them around the internet and then unpack them. And I could send them a completely different object than what they're expecting, and as long as the object I sent exists in one of the many libraries that program is using, it would still unpack it and execute its "I have just been unpacked" code?

    1. Michael Wojcik Silver badge

      Re: Have I got this right?

      It's not quite that simple. Usually deserialization doesn't in itself execute anything, and usually the application that's deserializing data from an unsafe source is doing something like this:

      1. Deserialize a data stream into an object graph.

      2. If that succeeds (it's a well-formed graph and all the necessary classes are available on the classpath), make sure it's an instance of what you were expecting.

      3. Do stuff with deserialized objects.

      The "Marshalling Pickles" presentation from AppSecCali 2015 that started this particular thread of inquiry1 showed some of the Really Dumb mistakes, like using a serialized object as an HTTP cookie and putting things like the user ID in it.

      But that was just a warm-up. The real meat of the presentation was an exploit that, in simplified form, did get code executed during deserialization, i.e. in step 1, before the application could get to step 2. Let's see if I can get this right from memory: apache-commons includes a "transformer" class that, among other things, would reflect on some other objects and execute methods in them, based on data in a map - as part of being deserialized. And another class in commons could be used to put arbitrary data into that map. So you serialize an object graph that includes the transformer and the other class and something of your own that implements Runnable, and during deserialization the transformer will invoke Run on your payload object.

      That's why statements like "it is not a flaw in Java itself, but instead a flaw in a widely used library" (Ullrich, quoted in the article) are dangerously misleading. Yes, the transformer implementation in commons is a Bad Thing. But pointing at libraries is just playing whack-a-mole. The core issue is deserializing untrusted data. And as I noted in another post above, there's a lot of that going around.

      A custom deserializer that whitelists object classes prior to deserialization helps. Whether it helps enough to be worth it is another question.

      Can you do the same thing with, say, .NET WCF? I don't know that you can with the stock framework binary serializer, because a quick look suggests it doesn't provide the same sort of hooks for classes to play silly buggers during their own deserialization. But XmlSerializer, for example, can be implemented using custom code (by implementing IXmlSerializable), and someone could certainly write an exploitable vulnerability into that. Then someone would have to create a WCF binding that used the vulnerable serialization method. So not likely to be a widespread problem, but there may well be some instances out there.

      1We've known for a long time that serialization led to some interesting attack vectors, of course. The MP presentation revealed some new exploit paths, among other things.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021