Explicit Serialization API and Security

[Peter Firmstone]

Don't forget that "null" may also be an invalid state.

What I have learnt so far:

   1. An attacker can craft a stream to obtain a reference to any object
      created during deserialization, using finalizers or circular links
      (there may be yet other undiscovered methods).
   2. An attacker can craft a stream that deliberately doesn't satisfy
      invariants, in order to use an object to perform a function that
      wasn't intended by its developer.
   3. Objects that interact with the stream directly using readObject et
      al, are often prone to DOS.  Example, many objects read a length
      integer from the stream when creating an array or collection,
      without first validating it.
   4. Objects that interact directly with the stream become an implicit
      part of the stream protocol.
   5. Once you allow an object to be created, it's too late to
      invalidate invariants, unless the class is final and invariants
      are checked in every method call.
   6. We need to be able to restrict classes used for deserialization to
      those we trust to check invariants properly (but we haven't
      provided a way for them to avoid object construction yet).
   7. A static validator method can ONLY be used to check field
      invariants, not other objects and primitives that are read
      directly from the stream by an arbitrary Object during the process
      of deserialization.
   8. The jvm can be modified to delay finalizer registration for
      deserialization.
   9. Circular links can be disallowed.

Ultimately however, all proposed changes add complexity, but when an 
object has been created with invalid invariants, an attacker will find a 
way.

Thank you all for your time, this has been a very good discussion.

Regards,

Peter.

On 22/01/2015 2:27 AM, Chris Hegarty wrote:
> On 20/01/15 20:22, Peter Levart wrote:
>> Hi Chris and Peter,
>>
>> It just occurred to me that the following scheme would provide failure
>> atomicity for the whole Object regardless of whether readObject methods
>> are used or not for various classes in hierarchy:
>>
>>
>> - allocate uninitialized instance
>> - call default accessible constructor of the most specific
>> non-Serializable class
>> - deserialize (by calling readObject methods where provided) the fields
>> of all classes in hierarchy like normally
>> (up to this point, nothing is changed from what we have now)
>> - if deserialization fails anywhere, undo everything by setting all the
>> fields in the Serializable part of the hierarchy to default values (null
>> for references, 0 for primitives), abandon the object and propagate 
>> failure.
>
> I think this is a good idea, and I can prototype something to this 
> affect.
>
> -Chris.
>
>
>> While deserializing, the object is in inconsistent state. If
>> deserialization fails, this state is rolled-back to uninitialized state.
>> finalize() can still get to the instance, but it will be uninitialized.
>>
>>
>> Peter
>>
>> On 01/14/2015 01:58 PM, Peter Firmstone wrote:
>>>
>>> Hi Chris,
>>>
>>> Sorry, no.
>>>
>>> Currently when an ObjectStreamClass is read in from the stream, the
>>> framework searches for the first zero arg constructor of a non
>>> serializable class and creates and instance of the class read and
>>> resolved from the stream, however it does so using a super class
>>> constructor.
>>>
>>> Then from the super class down, fields are read in and set in order
>>> for each class in the object's inheritance hierarchy.
>>>
>>> The alternative I propose, doesn't create the instance, instead it
>>> reads the fields from the stream, one by one and without instantiating
>>> them, if they are newly read objects, stores them temporarily into
>>> byte [] arrays in a Map with reference handle keys, otherwise it just
>>> holds the reference handle.
>>>
>>> What it does next is wrap this information into a caller sensitive
>>> api, GetFields or ReadSerial instance, that is passed as a constructor
>>> parameter to the child class serial constructor.
>>>
>>> The child class checks invariants and reads each field it needs using
>>> a static method prior to calling a superclass constructor, each class
>>> in the inheritance hierarchy for the object then checks its invariants
>>> until it gets to the first non serializable superclass.
>>>
>>> The benefit of this order is that each class is present in the thread
>>> security context, so protection domain security and invariants are
>>> enforced before instantiating an object.
>>>
>>> Hope this helps illuminate it a little better, regards,
>>>
>>> Peter.
>>>
>>> ----- Original message -----
>>> > Peter F,
>>> >
>>> > I am still struggling with the basic concept of you proposal. Let me
>>> see
>>> > if I understand it correctly. Does the following describe a similar
>>> > scenario as you envisage:
>>> >
>>> >    1) For each Serializable type, T, in the deserialized types
>>> >          hierarchy, starting with the top most ( closest to
>>> j.l.Object ),
>>> >
>>> >          1a) Read T's fields from the stream, fields
>>> >
>>> >          1b) validate(t, fields)  // t will be null first time
>>> >
>>> >          1c) allocate a new instance of T, and assign to t
>>> >
>>> >          1d) set fields in t
>>> >
>>> >    2) Return t;
>>> >
>>> > So for each level in the hierarchy, an instance of a type is created
>>> > only after its invariants have been checked. This instance is then
>>> > passed to the next level so it can participate in that levels
>>> invariants
>>> > validation.
>>> >
>>> > If this scenario is along the same lines as yours, then I just don't
>>> see
>>> > how 1c above will always be possible.
>>> >
>>> > If we could somehow make the object caller sensitive until after
>>> > deserialization completes, then could avoid having to try to allocate
>>> > multiple instance down the hierarchy.
>>> >
>>> > -Chris.
>>> >
>>> > On 13/01/15 10:24, Peter Firmstone wrote:
>>> > > Could we use a static validator method and generate bytecode for
>>> > > constructors dynamically?
>>> > >
>>> > > The developer can optionally implement the constructors.
>>> > >
>>> > > static GetField invariantCheck(GetField f);
>>> > >
>>> > > Create a caller sensitive GetField implementation and add a two new
>>> > > methods to GetField:
>>> > >
>>> > > abstract Object createSuper(); // to access superclass object 
>>> methods
>>> > > for inavariant checking.
>>> > >
>>> > > abstract Class getType(String name);
>>> > >
>>> > > Set fields from within constructors.
>>> > >
>>> > > The generated constructors are straight forward:
>>> > >
>>> > > 1. Call static method.
>>> > > 2. Call super class constructor with result from static method.
>>> > > 3. Set final fields
>>> > > 4. How to set transient fields, implement a private method called
>>> from
>>> > > within the constructor?
>>> > >
>>> > > Require a permission to extend GetField?
>>> > >
>>>
>>