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.




Reply via email to