Timeline for Why should I never ever ever use Java serialization?
Current License: CC BY-SA 4.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 25 at 11:27 | history | edited | Stack Exchange Broke The Law | CC BY-SA 4.0 |
added 188 characters in body
|
| Apr 23 at 12:55 | history | edited | Stack Exchange Broke The Law | CC BY-SA 4.0 |
added 110 characters in body
|
| Apr 19 at 16:57 | comment | added | Shaz | @MargaretBloom That's wonderful. You should put that in an answer, because it actually addresses the question of "Why should I never ever ever use Java serialization?" None of that is in the answer we're commenting on. | |
| Apr 19 at 16:56 | comment | added | Shaz | @StackExchangeBrokeTheLaw You never mention CVE-2010-0840 in your answer. This is absolutely wild to me how such a non-answer is getting any votes. Put this "easy to understand" information in your answer. We don't need scare tactics and platitudes we need technical information. | |
| Apr 19 at 15:29 | comment | added | Margaret Bloom |
is that it will execute invoke due to the outer InvocationHandler calling entrySet on its readObject method. This proxy instance invoke method is going to call get on its own memberValues. And what if we used Proxy<LazyMap> with a LazyMap that has transformer chain as outlined above? Boom, RCE. The InvocationHandler::readObject calls the Proxy<LazyMap>::invoke that calls LazyMap::get that kicks off the transformers chain to an RCE.
|
|
| Apr 19 at 15:29 | comment | added | Margaret Bloom |
Now, we only have to find an object that lookup in a map. InvocationHandler is the interface a Proxy obejct must implements, and have a custom readObject behaviour. When deserialized, this class call its memberValue entrySet method. We control memberValues, since the InvocationHandler is what is deserialized. If we set memberValues to another instance of a Proxy<Object> it will also run readObject but that's not relevant, what's relevant ...
|
|
| Apr 19 at 15:28 | comment | added | Margaret Bloom |
@Shaz ApacheCommons 3.x had an interface called Transformer to model what is now Function. They shipped a few implementations, particularly, InvokeTransformer (now disabled) that can invoke a method of a given object; and ConstantTransformer that can load a constant object. It is now clear that you can ChainTransformer a few transformers to invoke Runtime.getRuntime().exec("whatev"). The chain needs to be invoked, though. AC also have a LazyMap that is compatible with Transformer: when a LazyMap.get gets invoked with a non existing object, the chain is triggered.
|
|
| Apr 18 at 17:52 | history | edited | Stack Exchange Broke The Law | CC BY-SA 4.0 |
added 44 characters in body
|
| Apr 18 at 16:31 | history | edited | Stack Exchange Broke The Law | CC BY-SA 4.0 |
added 216 characters in body
|
| Apr 18 at 15:17 | comment | added | Stack Exchange Broke The Law | @Shaz I don't understand the particular chains they used since they rely on a bunch of classes I'm not familiar with, however that it's a similar principle to CVE-2010-0840 "Trusted Method Chaining" and I find that one easy to understand. It's not exactly the same thing since in CVE-2010-0840 the attacker got to load some classes and serialization wasn't involved. | |
| Apr 18 at 9:41 | comment | added | Basilevs | Proxy is a an object that implements methods defined at runtime, not at compile time. Each call of its methods is dispatched via stringified method name, just like in an interpreter, this effectively allows to transform data into behavior. | |
| Apr 18 at 9:38 | comment | added | Basilevs | @shaz, as far as I understand, Proxy object is supplied with a serializable InvokeHandler. And then that handler would be called when readObject method is eventually invoked. Read on Java Proxies and traverse Github references it might be easier to understand. | |
| Apr 18 at 1:33 | comment | added | Shaz | @Basilevs How? That's my question. This is a technical forum. Go down to the bits. If it's bad, how is it bad? How bad is it? I can run arbitrary code and escalate privileges with XML does that mean no one should use XML? No.... This currently reads like saying buffer overflows are bad, so never use arrays or pointers. That's obviously not realistic. How does reality play into this? What's the actual problem and how can people mitigate it? | |
| Apr 18 at 0:49 | comment | added | meriton |
In modern Java, Oracle recommends Serialization Filtering rather than overriding resolveClass.
|
|
| Apr 17 at 22:51 | comment | added | Basilevs | @Shaz the linked exploit uses an existing class, which evaluates parts of content upon deserialization. Content can be maliciously formed. | |
| Apr 17 at 18:46 | comment | added | Shaz | What is the exploit? How does it actually work? (Not just that it is in readObject) I've read a good portion of the linked materials and haven't been told how it can actually be exploited. But regardless that should be in this post since external materials can change or become dead links. What is "evil code"? I think it's sufficient to say arbitrary code execution without editorializing. Also this answer has been left in an incomplete state. It honestly just feels like an advertisement for the linked blog at this point. | |
| Apr 17 at 0:25 | history | answered | Stack Exchange Broke The Law | CC BY-SA 4.0 |