State of Serialization

Peter Firmstone peter.firmstone at
Sat Jul 26 09:57:51 UTC 2014

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?



More information about the core-libs-dev mailing list