river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Security
Date Sat, 07 Feb 2015 03:55:59 GMT
Thanks Dan, hopefully I don't dissapoint.

... So continuing on, another benefit of secure Serialization, if you're 
a lookup service, you don't need to authenticate your clients, you can 
deal with anyone and your not subject to DOS attacks, other than more 
conventional attacks unrelated to java.

I've been investigating Serialization security, identifying issues and 
considering how to deal with them. I think everyone is aware 
Serialization has security pitfalls, if I fail to mention an issue 
you're aware of, please let me know.

At first I thought it was just an issue of limiting the classes that 
could be deserialized and that's relatively easily done, for example, 
ArrayList reads an integer from the stream, then uses it to create an 
array, without sanity checking it first.  Well that's easy, just prevent 
ArrayList and a bunch of others from deserializing...

Not so fast, ObjectInputStream also creates arrays, without sanity 
checking, blockdata also has similar issues during byte array creation.

So you only need send an Integer.MAX_VALUE to bring the jvm to it's 
knees, and if that doesn't do it, send a multi dimension array with a 
few more.   It requires very little data from the sender, just a few 
bytes and a couple of integers.

In addition ObjectInputStream caches objects, so they don't have to be 
re-serialized, but if ObjectOutputStream  doesn't perform a reset, well 
you can figure that out without my help.

But wait there's more...

During deserialization, Serializable objects are instantiated by calling 
a zero arg constructor of the first non Serializable super class, this 
partially constructed Object, an instance of a Serializable child class, 
without any invariant checks or validation, is then allocated an integer 
handle and published, an attacker is now free to obtain a reference to 
the unconstructed object simply by inserting a reference handle into the 

At this time the ProtectionDomain's of the classes in the object's 
heirarchy are not present in the AccessControlContext, which is why 
attackers in the past have been able to creat ClassLoader instances and 
download code, when someone has deserialized into privileged context 
(that renders DownloadPermission useless, because the attacker can work 
around it).

After unsafe publication, the fields are read in from the stream from 
super class to child class and set.

Now I don't blame the developers back in the day, they had deadlines and 
targets to achieve, but  the market has changed significantly since then 
and the issue needs addressing.

The good news is, the Serialization stream protocol has all the 
components necessary to create a secure ObjectInputStream.

For example, the stream cache can be reset periodically, this also means 
we can place a limit on the number of objects cached, and require  
ObjectOuputStream to call reset.  If it doesn't and the object cache 
exceeds our limit, StreamCorruptedException.

For array length, again we can impose limits, and throw 
StreamCorruptedException if the limit is exceeded.

The collections themselves aren't hard to solve, simply replace all 
collection types with a safe replacement in ObjectOutputStream and 
require DeSerializationPermission for known insecure objects.

Circular links, can't be supported using existing deserialization 

Does this last point matter?

My implementation of ObjectInputStream doesn't support circular links 
and passes all lookup service tests.  In this case circular links are 
replaced with null.  To support circular links safely would require some 
cooperation from the classes participating in deserialization.

Construction during deserialization is the last challenge, many existing 
Serializable classes don't have public constructors or zero arg 
constructors, even though implementing Serializable is equivalent to a 
public constructor.

... to be continued, until next time.



On 5/02/2015 2:38 AM, Dan Rollo wrote:
> Very interesting. Looking forward to the next episode.
>> On Feb 4, 2015, at 9:11 AM, dev-digest-help@river.apache.org wrote:
>> to be continued...

View raw message