Explicit Serialization API and Security

[David M. Lloyd]

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.

-- 
- DML