7

i would like to be able to spot problems with deserialization in java code. What should i look for? For example, how would one determine if some java code tries to exploit "java calendar bug"? Note that i'm not a java programmer, but i understand the concepts behind serialization and OOP fine. I'm trying to implement some safety checks (something like a compiler warning tool).

EDIT: based on comments i would like to change the question a bit: I consider all the code analyzed "untrusted", is there a way how to rate the potential danger? I mean, can i tell that code A is more dangerous than B with regard to deserialization bug? What should i look for?

PeterK
  • 6,287
  • 5
  • 50
  • 86

4 Answers4

5

Firstly you need to understand your context to determine security threats. (When I talk about "trust", I'm taking little short cut. I'm talking deliberately malicious.)

If the serialised data was created, kept and read with the same trust, then there isn't any real problem (other than standard bugs). Note if you write any sensitive information, then the serialised data is also sensitive (it seems obvious, but there is a fair amount of indirection there).

If the the serialised data is untrusted for whatever reason, then there is a little more to consider. The internal structure of the recreated objects may be "unusual". The data may not be consistent. You may have shared mutable objects which should be separate. Deserialisation may cause an infinite loop, or a non-infinite loop which just happens not to be completable before the heat death of the universe. And of course the data may be lies.

If you are writing library code that is used by less trusted code, then things get more interesting:

In the case of "calendar bug" (and similar), that is about deserialising an arbitrary stream with malicious data and malicious code. The Java Secure Coding Guidelines suggests doing security checks (using the "Java2 Security Model") within custom readObject methods, which implies that you shouldn't call deserialisation with more trust than the code and data has.

From the side of deserialisable objects, things are more tricky. Objects provided by ObjectInputStream through readObject, readUnshared, defaultReadObject, readFields or just the default deserialisation may have references captured by malicious code or, for non-final classes, be subclassed maliciously. An object may also be used during deserialisation, when partially initialised. Deserialisation does not invoke a "real" constructor of the deserialised class (readObject/readObjectNoData is a kind of psuedo-constructor, which can't set finals). It's all a bit of a nightmare, so you probably don't want to make your sensitive classes serialisable.

There have been a number of vulnerabilities in the implementation of serialisation and deserialisation. You don't really need to worry about this, unless you are implementing it yourself.

Tom Hawtin - tackline
  • 145,806
  • 30
  • 211
  • 305
2

Hmm... your question is a bit general. Did you take a look at this article? It's about Java's serialization algorithm, but from Google's cache because the main page seems to be down at the moment.

darioo
  • 46,442
  • 10
  • 75
  • 103
  • Thanks for the article, i will go through it. I know my question is a bit too general, but i want to cover the issue in a generic way. – PeterK Nov 01 '10 at 13:06
1

I'd have thought that the best way to defeat code that exploits known security holes in Java is to upgrade to a Java version that fixes the bug. And the next best way (to deal with serialization related bugs) is treat all serialized data from unknown / unverified / insecure sources as suspicious.

Trying to spot problems by analyzing java code for security bugs isn't easy, and requires a deep understanding of the Java mechanisms that are being used and could be exploited. Trying to spot attempted exploits (in general) would be even harder, especially if you are looking for exploits for zero-day security holes. Bear in mind that there are other potential vectors.

(If there were easy ways to find unknown security holes in Java, you can bet that Sun and other security researchers would have already used them.)

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • Good point! Thanks for the answer. Please see the edited question, i changed it a bit, perhaps that will lead somewhere. – PeterK Nov 01 '10 at 13:20
  • @PeterK - Honestly, I don't know what to look for. But once again, if there were known things to look for, you'd expect Sun and others to have looked already. For instance, I imagine that discovery of the Calendar hole prompted a flurry of internal code reviews. – Stephen C Nov 01 '10 at 13:33
  • You're better off doing both. Upgrade and treat all serialized data as untrusted. – Antimony Jul 17 '13 at 14:58
1

If you serialize your Java object to transfer it to a separated application, why not consider signing the object with a key shared between applications? It should be enough to defend yourself from man-in-the-middle attack.

Going back to the core of the verification problem, the verification is extremely difficult for general purpose languages. You should look for scientific publications on this topic. I think the most commonly applied technique is sandboxing. The second approach is to restrict the language and disallow the execution of dangerous commands, e.g., Yahoo Caja library uses this technique.

Skarab
  • 6,981
  • 13
  • 48
  • 86