Explicit Serialization API and Security

David M. Lloyd david.lloyd at redhat.com
Mon Jan 5 14:17:57 UTC 2015

On 01/03/2015 09:36 AM, Peter Levart 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.
> Is there anything in JLS that guarantees finalization for instances
> which fail construction or deserialization? 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
> deserialization

How about simply forbidding classes with finalizers from being 
serialized or deserialized with this mechanism?  Finalizers never really 
work the way you want anyway.

Seems a better option than essentially doubling (or more) the end-user 
complexity to me.


More information about the core-libs-dev mailing list