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- …
...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.
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.
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.
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).
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
...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
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.
"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?
@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.
"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.
This post has been deleted by its author
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.
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.
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.
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?
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
