State of Serialization

[Peter Firmstone]

Updated files attached, including update to State of Serialization draft.

Note that the attached source code can be provided under the Oracle 
agreement.

I'm a little time poor, so please contribute suggestions etc.

Regards,

Peter.

On 26/07/2014 7:57 PM, Peter Firmstone wrote:
> I'm somewhat time poor at present, it's a draft.
>
> The intent is to open a discussion to:
>
>   1. Address security issues
>   2. Make Serializable2 api completely public and backward compatible 
> with the existing serial stream protocol.
>   3. Allow Serializable to be switched off via a jvm switch
>
>
> On 22/07/2014 1:10 AM, Tom Hawtin wrote:
>> On 20/07/2014 11:57, Peter Firmstone wrote:
>>
>>> 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.
>>
>> It's more complicated than that. Even final serialisable classes may
>> have security checks.
>
> You've highlited an issue with security on the Java platform, it's 
> possible for an object to escape after a security check has been 
> performed by a constructor.
>
> It's bad practise for a Serializable object to have a security check 
> from within it's constructor, however a Serializable object may extend 
> an object with a zero argument constructor, such as ClassLoader.
>
> The trick for an attacker is to deserialize within a privileged 
> context, even when a ClassCastException occurs, it does so after the 
> object has been created, if an attacker can get a reference to it 
> before it's garbage collected...
>
> Prior to calling a constructor, if a class hasn't been loaded, class 
> static initializers are also called.
>
> Li Gong proposed the method guard pattern, page 176, inside Java 2 
> Platform Security, second edition, this fixes the issue of objects 
> that potentially escape, however performance with the existing 
> security infrastructure is a problem, that can be easily fixed, but 
> that's another topic (on security-dev).
>
> What we really need to do is enable an administrator to limit classes 
> allowed to be Serialized, via a configuration file, with Java 9, we'll
> need to know which module too.
>
>>
>>> 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.
>>
>> Certainly it would be better have a mechanism that better fitted in
>> with non-serialisation mechanisms. Addressing this without unraveling
>> too much when pulling on a thread, and without increasing complexity
>> of corner cases, is non-trivial.
>
> By providing a new interface, using only public api, but also the same 
> stream format, an upgrade and backward compatible path can be provided.
>
> This allows both interfaces to co-exist and for corner cases to remain 
> supported within Serializable, however it would also allow 
> administrators to switch off Serializable and use only Serializable2.
>
> Complicated?  How so?
>
> Regards,
>
> Peter.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: State of Serialization.odt
Type: application/vnd.oasis.opendocument.text
Size: 17772 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140728/f2c498e1/StateofSerialization-0001.odt>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140728/f2c498e1/package-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Portable.java
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140728/f2c498e1/Portable-0001.java>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: PortableFactory.java
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140728/f2c498e1/PortableFactory-0001.java>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: PortableObjectInputStream.java
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140728/f2c498e1/PortableObjectInputStream-0001.java>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: PortableObjectOutputStream.java
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140728/f2c498e1/PortableObjectOutputStream-0001.java>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: PortablePermission.java
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20140728/f2c498e1/PortablePermission-0001.java>