Explicit Serialization API and Security

[Peter Firmstone]

P.S. Thanks for engaging this difficult subject.

It's worth remembering the finalizer attack isn't the only issue, a subclass will have a reference after construction completes, it has a thread of execution and if the superclass hasn't checked invarients, because circular links haven't been wired up, it's game over.

For explicit serialization, this is only a problem for circular relationships.

A permission check for extension can be performed before Object's constructor is called, or the class can be final.

That leaves the case of determining which of two objects is trusted to pass a reference before invarients have been checked.  One of the objects in the circular relationship could be the attacker and we just gave it a reference before checking invarients.

Once created, an object has little control over references to it.

So it would seem that circular links would only be allowed on trusted serial data, for network connections, that means an authenticated, secure connection.

So a class that implements Circular would require a permission check to be performed after the Circular object is created, but before passing a reference that wires up a circular link.

So it becomes a case of:
1.  Do I trust my subclass?
2.  Do I trust the framework?
3   Am I trustworthy?
4.  Can I trust classes loaded after my constructor completes, to receive my reference, even though I haven't checked invarients and to honour my wishes and delete my reference if I find invarients aren't satisfied?

Peter.

----- Original message -----
> Just a quick comment about the finalization aspect ( as I have been
> thinking about this too ).
> 
> On 3 Jan 2015, at 15:36, Peter Levart <peter.levart at gmail.com> wrote:
> > On 01/03/2015 01:38 PM, Peter Firmstone wrote:
> > > 
> > > > Hi,
> > > > 
> > > > I would like to know what are the potential issues with simple
> > > > constructor chaining where each constructor checks the invariant
> > > > of its class state (with the already initialized state of
> > > > superclass(es)).
> > > 
> > > Finalizer attack; a subclass can override the finalize method and
> > > receive a thread of execution, even when it hasn't gotten hold of a
> > > reference during construction. It's best to prevent an object's
> > > construction, by throwing any exceptions before Object's default
> > > constructor is called.
> > > 
> > 
> > As Brian points out, this scheme can only validate intra-class
> > invariants. It can't validate class-against-subclass state. And, the
> > finalize() method will be called anyway - although this time with
> > fully uninitialized instance (all fields default values). If this is
> > safer, then alright.
> 
> In many cases default values will be safer, but not always, e.g. port
> number of ‘0’ implies ephemeral port.
> 
> > Is there anything in JLS that guarantees finalization for instances
> > which fail construction or deserialisation?
> 
>   "An object o is not finalizable until its constructor has invoked the
> constructor for Object on o and that invocation has completed
> successfully (that is, without throwing an exception).” [1]
> 
> It is unfortunate that the way default serialization constructs objects,
> the j.l.Object constructor is invoked before attempting to set any
> fields.
> 
> > Wouldn't it be better to "register" for finalization just those
> > instances that complete their construction or deserialization
> > normally? I'm just trying to understand why it is the way it is.
> > 
> > Would something like this prevent Finalizer attacks?
> > 
> > - leave finalization registration the way it is (at object allocation
> > time). - provide internal API with which a previously registered
> > object can be de-registered - deserialization infrastructure
> > de-registers the instances that fail deserialisation
> 
> I have given this some thought too, and also think that deserialized
> objects should not become finalizable until after the fields have been
> successfully set. Whether this be an internal API, JLS change, or an
> extension to the “magic” serialization mechanism to invoke the first
> non-serializable classes no-args constructor, I’m not sure.
> 
> -Chris.
> 
> [1]
> http://docs.oracle.com/javase/specs/jls/se7/html/jls-12.html#jls-12.6.1
> 
> > 
> > Regards, Peter
> >