
The Java Deserialization Bug - ingve
http://fishbowl.pastiche.org/2015/11/09/java_serialization_bug/
======
matt_heimer
The linked article says "No such safe method is available for Java
serialization, so your best bet in Java is not to use Java serialization
unless you absolutely trust whoever is producing the data".

This is wrong. It is trivial to mitigate this issue and it only takes a couple
of lines of code. For a step-by-step guide from 2013 see
[http://www.ibm.com/developerworks/library/se-
lookahead/](http://www.ibm.com/developerworks/library/se-lookahead/)

~~~
pron
Another way to solve this it is to only call
readResolve/readObject(ObjectInputStream) under a different security policy (a
different AccessControlContext from the caller). The problem is that both
approaches (lookahead or security policy) require you to use a custom
ObjectInputStream class.

------
matt_heimer
Better information on which class (InvokerTransformer) is being exploited
[http://foxglovesecurity.com/2015/11/06/what-do-weblogic-
webs...](http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-
jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/)

The related Apache ticket:
[https://issues.apache.org/jira/browse/COLLECTIONS-580](https://issues.apache.org/jira/browse/COLLECTIONS-580)

------
alblue
It's not just Apache Commons that's affected - other libraries such as Spring
and Groovy have similar vulnerabilities. My write up at InfoQ is here:

[https://news.ycombinator.com/item?id=10526953](https://news.ycombinator.com/item?id=10526953)

------
kevinherron
This is quite serious; not sure how we didn't all start hearing about this
back at the end of January.

~~~
draw_down
January?

~~~
matt_heimer
January was when some slides from a talk were posted -
[http://www.slideshare.net/frohoff1/appseccali-2015-marshalli...](http://www.slideshare.net/frohoff1/appseccali-2015-marshalling-
pickles)

------
jtheory
I don't think I've ever worked on a project that deserialized untrusted Java
objects; where does this come up?

I suppose -- if you have a Java client for a (probably) EJB-based server; most
of the cases where I imagine this sort of setup are with internal-only
solutions, though, which mitigates the risk somewhat (but obv. it would still
need to be corrected).

I've read about banks in some countries still commonly using Java applets for
site access -- that could be a seriously-dangerous attack vector.

~~~
Nelson69
I've been trying to figure that out too. Part of it is certainly some kind of
bug hunter fame that is being played for.

That just seems like bad architecture, period. Now if this can be exploited
with RMI or something, I wouldn't be too shocked to see some client/server
type applications using that as an interface.

are there session cookies that are serialized objects or something?

------
notZeroDay
This is not so much a "zero-day" vulnerability, since the topic was discussed
back in January, albeit with little fanfare. That it did not receive much
attention until last week, doesn't mean it's really a sudden exploit
discovered being used maliciously in the wild.

This was a tech talk intended to broach the subject of dangerous, but standard
features of the Java serialization API, providing a demonstration of proof of
concept attack vectors.

The truth is that this is not actually a bug. The code works as the design of
the OPTIONAL THIRD PARTY library intends. The problem is that this is code
that people carelessly deploy, accidentally exposing themselves to attack,
failing to understand the full scope and capabilities of their servers and the
features they've accidentally included by default.

------
aaronharnly
Trust is relative, of course; one should be extremely wary of data that came
from an external user, or a client-side application. None of us would say one
should naively deserialize such data.

But then there's data that comes from another team's server calling yours as a
service; or from another server internal to your service; or off an internal
message bus; or from one's own database.

Each of these has a different degree of trust, and different considerations to
weigh.

------
CountHackulus
So it's not a Java bug, it's an Apache Commons-Collection bug. Granted, it's
an extremely popular library, but it's not a "Java" bug.

~~~
skybrian
The bug is that doing deserialization safely is difficult in the presence of
inheritance, since it's an open-world type system.

If a serializable object contains a field of type Foo, this implies that all
subtypes of Foo can be transmitted, whether they were designed with
serialization in mind or not. This is especially bad for commonly used base
types such as List or Exception. At the limit, if you have a field of type
Object or Any, there's no choice but to use an explicit whitelist.

Contrast with how Go does unmarshaling in its standard library (which works
with structs and arrays but not interfaces), and functional languages (which
use unions in the form of algebraic data types, not inheritance). These are
closed-world type systems where we can generate the whitelist by walking the
type tree from the base type.

~~~
hyperpallium
Restricting serialization to JSON-like objects loses the benefit of being able
to "serialize objects". (However, having that separate internal format for
data may well be a better way to go, in general.)

The algebraic approach, in this context, is similar to a superclass naming its
subclasses (rather than a subclass naming its superclasses as java does). I'm
not sure, but I suspect this open-world choice is deliberate, allowing
extensibility. Java is very attentive to security considerations elsewhere. It
also would be a too-dramatic change for mainstream OO programming languages.

A third approach is explicitly closed-world: naming the set of classes
permitted for deserialization, as per some other commenters. e.g. JAXB does
this by necessity, for binding to XML Schema's algebraic type system.

~~~
pron
> naming the set of classes permitted for deserialization

Or simply having ObjectInputStream execute
readResolve/readObject(ObjectInputStream) under a different security context.
No need for whitelisting.

------
TazeTSchnitzel
> arbitrary object deserialization [...] is inherently unsafe

Is it always? In a language with side-effects (like Java), maybe, but in
something like Haskell, surely it would be completely safe?

~~~
CJefferson
In Haskell you could still escape with System.IO.Unsafe at any time.

of course you could check your desiralised code isn't doing anything unsafe,
but that's fairly easy to do in Java too.

~~~
codygman
The way to do so in Haskell is putting "Safe" in the Language section of a
cabal file, and it covers other stuff like partial functions IIRC.

Are you saying that Java has something similar to SafeHaskell? Are you saying
they are nearly the same? If yes to the last one, I feel that might be untrue.

It's quite possible I just read through your comment too quickly though.

~~~
CJefferson
In Java, it's easy to run code under a SecurityManager, which lets you
carefully control exactly what other classes the code can access. This gives
you really fine-grained control, and lets you control very carefully what code
is doing.

