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.
