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.
