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
stream.
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
mechanisms.
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.
Cheers,
Peter.
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-h...@river.apache.org wrote:
to be continued...
