State of Serialization

[Peter Firmstone]

I'm somewhat time poor at present, it's a draft.

The intent is to open a discussion to:

   1. Address security issues
   2. Make Serializable2 api completely public and backward compatible 
with the existing serial stream protocol.
   3. Allow Serializable to be switched off via a jvm switch


On 22/07/2014 1:10 AM, Tom Hawtin wrote:
> On 20/07/2014 11:57, Peter Firmstone wrote:
>
>> Since private methods are only be called by the ObjectOutputStream /
>> ObjectInputStream, during de-serialisation, subclass are not responsible
>> for calling these methods, hence subclass ProtectionDomain's are not
>> present in the Thread's AccessControlContext and as such are missing
>> from security checks, this is why it's currently essential for classes
>> to ensure that de-serialisation isn't performed in a privileged context.
>
> It's more complicated than that. Even final serialisable classes may
> have security checks.

You've highlited an issue with security on the Java platform, it's 
possible for an object to escape after a security check has been 
performed by a constructor.

It's bad practise for a Serializable object to have a security check 
from within it's constructor, however a Serializable object may extend 
an object with a zero argument constructor, such as ClassLoader.

The trick for an attacker is to deserialize within a privileged context, 
even when a ClassCastException occurs, it does so after the object has 
been created, if an attacker can get a reference to it before it's 
garbage collected...

Prior to calling a constructor, if a class hasn't been loaded, class 
static initializers are also called.

Li Gong proposed the method guard pattern, page 176, inside Java 2 
Platform Security, second edition, this fixes the issue of objects that 
potentially escape, however performance with the existing security 
infrastructure is a problem, that can be easily fixed, but that's 
another topic (on security-dev).

What we really need to do is enable an administrator to limit classes 
allowed to be Serialized, via a configuration file, with Java 9, we'll
need to know which module too.

>
>> To improve security, it would be preferable to use a deserialization
>> constructor, required to be called by subclasses in the class
>> hierarchies, placing their ProtectionDomains in the stack context,
>> avoiding a number of security issues. Another benefit is the ability to
>> use final fields, while checking invariants during construction.
>
> Certainly it would be better have a mechanism that better fitted in
> with non-serialisation mechanisms. Addressing this without unraveling
> too much when pulling on a thread, and without increasing complexity
> of corner cases, is non-trivial.

By providing a new interface, using only public api, but also the same 
stream format, an upgrade and backward compatible path can be provided.

This allows both interfaces to co-exist and for corner cases to remain 
supported within Serializable, however it would also allow 
administrators to switch off Serializable and use only Serializable2.

Complicated?  How so?

Regards,

Peter.