Improving the control of serialization

[Eirik Bjørsnøs]

Stephen,

The overloaded readObject is interesting, but that will only be able to
validate the top level object right? So if you're deserializing a
collection, how would you be able to validate nested types?

ObjectInputStream already has resolveClass which could be used to validate
any classes loaded during deserialization, as described here:

http://www.ibm.com/developerworks/library/se-lookahead/

So in a way this is a solution which is already here. I just don't think
people have been using it much.

Eirik.

On Tue, Nov 10, 2015 at 7:22 PM, Stephen Colebourne <scolebourne at joda.org>
wrote:

> 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.
>