Towards better serialization

[Kłeczek, Michał]

On 13/06/2019 15:37:34, "Brian Goetz" <brian.goetz at oracle.com> 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;
   @Deserializer
   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

PS:
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 
:)

--
Michal