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.

Reply via email to