Improving the control of serialization

[Stephen Colebourne]

A mechanism like this could well be useful in the JDK.

Worth also noting this tweet:
https://twitter.com/mebigfatguy/status/663289401301143552
which suggested adding an overload of readObject() on
ObjectInputStream that accepts a Class and validates that the
deserialized type is expected.

Stephen




On 10 November 2015 at 12:51, Eirik Bjørsnøs <eirbjo at gmail.com> wrote:
> 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.