State of Serialization

[Peter Firmstone]

On 28/07/2014 7:28 PM, Peter Firmstone wrote:
> Updated files attached, including update to State of Serialization draft.
>
For those who didn't get the attachment:

*State of Java Serialization - Draft*


  Introduction

The Java Serialization framework enables object state to be frozen, 
stored to disk or transferred over a network and unfrozen again into 
objects. While Java's Serialization capabilities are arguably more 
sophisticated than most at reconstructing complex object relationships, 
the “magic” nothing to do, marker interface, Serializable is 
problematic. Due to the complexity of serialising state from an object 
with Serializable superclasses in inheritance hierarchies, private 
methods were chosen, allowing objects to write and read objects to and 
from streams. Each class in an Object's inheritance heirarchy that 
implements or inherits Serializable must be able to write out and read 
in serialized state, private methods cannot be overridden or called by 
subclasses, nor is their implementation enforced by the Java language 
syntax, hence Serializable is a marker interface only.


  Background

Serialization was introduced in Java 1.1. The marker interface 
Serializable is problematic since implementation of its methods are 
optional. Developers can make objects serializable by simply declaring 
implements Serializable and providing a default zero argument constructor.

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.

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.


  Challenges


    Cyclic data structures

Presently an ObjectInputStream creates a new Object using a zero arg 
constructor, then populates its fields from superclass to child class. 
It's possible to obtain a reference to an object before fields have been 
populated, allowing reconstruction of circular relationships between 
objects.

Cyclic data exists because either during construction the “this” 
reference has escaped to a trusted object, or after construction it has 
been passed via a mutating method.


    Options for repopulating cyclic data using deserialization constructors


      Option 1, deliberately allow “this” to escape during construction

In order for a deserialization constructor to populate a circular data 
structure with its reference, the constructor must accept a parameter 
object that reconstructs the circular data structure and the new object 
must be prepared to pass its “this” reference to the parameter object 
during construction.


        Issues with allowing “this” to escape during construction

When “this” escapes to reconstruct a circular data relationship during 
construction it causes the following issues:

   1.

      It is not possible to us a static method to create field objects,
      validate invariants and throw an Exception, before the Object
      superclass constructor has been invoked to avoid finalizer attacks.

   2.

      Defensive copying, if the “this” reference is defensively copied
      during construction of a new field from the OIS, the state copied
      may only be partially constructed.

   3.

      The “this” reference may be copied by using a hand crafted object
      stream, prior to a constructor completing.


      Option 2 Create a new Serialization mechanism, preserve and limit
      existing Serializable classes.

   1.

      Existing Serialization can be limited to classes known to be safe
      using a mechanism similar to look ahead serialization.
      http://www.ibm.com/developerworks/java/library/se-lookahead/index.html


   2.

      Provide a configuration file allowing administrators to define
      trusted Serializable classes.

   3.

      A working proposed alternative that provides “most of the
      abilities of Java Serialization” without the security risks has
      been attached that can be used as a baseline.

          o

            Constructors are the only method of creating objects

          o

            Objects constructors are called with default minimal
            privileges (only grants in policy files made to all).

          o

            Objects are responsible for wiring up their own circular
            relationships.