Towards better serialization

Kłeczek, Michał michal at
Thu Jun 13 16:24:52 UTC 2019

On 13/06/2019 15:37:34, "Brian Goetz" <brian.goetz at> wrote:

>Having read through all of what you’ve written in this thread, let me summarize it more succinctly:
>“There are users of serialization who have never used serialization in more than the most trivial manner, who have never been on the wrong side of a serialization vulnerability, and who really like the illusion of magic serialization dust that it provides.  Please don’t take that away from us.”
>And, I get it; this is the siren song that led us to the serialization framework we have, with all its complexity and security pain.  But I think we should learn from history.  You’re arguing “serialization is good enough”, or that small add-ons would solve the problem.  Having been on the wrong side of too many serialization security issues, I disagree.
>As a public service announcement, let me point out how a rhetorical trick might be tripping you up: you use the word “simply” everywhere, as in:
>>  Why don't we simply make it easier
>(and others.)  But there’s nothing simple about it; adding “simply” serves only to make it sound simpler than it is — and therein lies the danger.
The whole premise of the proposal we are discussing is that convenience 
is the root of all evil.
But this convenience is actually the root of such a wide use of existing 
serialization. And yes - we mere mortals need this convenience.
Taking it away will only cause popping up ad-hoc solutions that will be 
even worse. XStream anyone?
Heck - I have even seen passing Spring XML via the network and 
recreating application context based on that!
As you are surely aware of: _most_ serialization security 
vulnerabilities equally well apply to other serialization frameworks.
The reason is that it is not serialization as such that is a security 
problem - and I was trying to point out that even the example from the 
discussed paper illustrates it.

This deserialization gadget:

class Gadget {
   final Delegate delegate;
   Gadget(String cl, String method, Object[] arguments) throws Throwable 
     this.delegate = (Delegate) Class.forName(cl).getMethod(method, 
getArgTypes(arguments)).invoke(null, arguments);

is no less evil than the one that uses reflection in readObject() - even 
more so as it gives false sense of security by meeting some invariants.

Summing it up:
A "better" serialization framework needs to be:
- at least as convenient
- at least as flexible
- more secure

What we've got is:
- less convenient
- less flexible
- no more secure

I am far from rhetorical tricks - English is not my native language and 
what might sound like a trick is just poor language usage from my side 


More information about the amber-dev mailing list