Improving the control of serialization

[Eirik Bjørsnøs]

Hi,

I just watched the "Ask the JVM Architects" session from JavaOne 2015:

https://www.youtube.com/watch?v=iHHSa39p48I&t=7h59m45s

where an interesting question came up: "What would you remove from Java if
you could go back?"

Mark and Brian both voted for (or against) serialization. (John and Alex as
usual answered with something sounding completely reasonable and smart but
that I understood very litte of :-)

With the recent discussion of deserialization attacks, wouldn't it be cool
if the JVM allowed us a little more control over which classes it should
allow deserialization of?

As an experiment and also as a mitigation effort against deserialization
attacks I created the Java Agent NotSoSerial:

https://github.com/kantega/notsoserial

NotSoSerial can operate in a whitelisting mode where you give it the names
of classes which should be allowed for deserializarion. (It does this by
adding/altering readObject methods to any Serializable class such that it
throws an exception).

Configuring an empty whitelist effectively disables deserialization
completely. And it turns out that many applications work just fine with
this. So why allow the risk of some library doing deserialization?

So back to the "Ask the JVM architects" question:

Could and should we add mechanisms to the JVM which would allow us to
control or disable control the use of deserialization?

What would a possible solution for this? At what level does that solution
belong? Or does something like this exist that I'm just not aware of?

Cheers,
Eirik.