Friday, April 9, 2010

Javocalypse

EDIT: Following its full disclosure Sun fixed Tavis' Java deployment toolkit bug (CVE-2010-0886 and CVE-2010-0887) in a matter of days, wow! No doubts this will be used in the future as an argument for full disclosure.
However, this does not bring much security! An attacker can still automatically downgrade your version of Java (using installJRE) and exploit this bug or any other he likes!

Almost one year ago, I blogged about one of my favorite security bug, found by Sami Koivu.

More specifically, I blogged about a class of Java bugs exposed by Sami Koivu and I mentioned this was the first instance of it.

Not only was it interesting from a technical perspective, but also high impact, allowing perfectly reliable (and relatively simple) cross platform exploitation of any system supporting Java applets (and that's a lot of systems). And this, through a widely deployed, but notoriously poorly updated component.

One year later [1], Sami strikes again. This time should be the final nail in Java applets' coffin for anyone with security expectations:
  • Another instance of the privileged deserialization class of bugs (CVE-2010-0094)
  • A new class of bugs: Java trusted method chaining. With one instance as a free sample (CVE-2010-0840). (This one is beautful by the way, be sure to read!)
  • Free goodies for web security researchers: a flaw that completely breaks the web security model. The "Java-SOP" security was done in the compiler, not the runtime (CVE-2010-0095). Normally this would translate to "really bad", but why would one need your cookies when one can have your computer?
But Tavis would not let Sami have his party alone and between two kernel bugs took a quick look at the Java deployment toolkit and found this embarrassingly trivially exploitable issue. It's not corrected yet. And it's exploitable even if you have Java disabled in IE or Firefox, you only need to have Java installed.

It's so simple that it was obvious that many people had found (and were exploiting) this one. And we've already had confirmation of this, which led Tavis to release his advisory with mitigation instructions before a patch was available. Read his advisory for interesting thoughts on disclosure.

So, dear reader, if you don't want to get owned multiple times:
  • Disable Java in your web browsers
  • Uninstall Java completely or follow Tavis' mitigation instructions on Windows
Updating Java does not work, Sami has already mentioned that he would be very surprised if there weren't 10 other cases of "Java trusted method chaining" bugs. There are probably other deserialization ones too.
And anyway, a lazy attacker can just silently downgrade his up-to date target to whatever vulnerable Java version he wants to exploit, using the aforementioned Java deployment toolkit. Really, it's a feature.

Moreover, not everyone can update Java. Let's see how long it takes for Apple to patch these ones this time. My bet is that up-to-date default MacOS X installations are going to be vulnerable for a while to even the publicly reported bugs.

This is Javocalypse.

[1] well technically, only a few months later, but it took 5 months before the public advisory. A delay that I would call "reasonable".

8 comments:

  1. What I find especially interesting is looking at http://java.sun.com/javase/6/webnotes/6u17.html they have apparently "fixed" Travis's bug once (#6869752). Would love to know what it was they supposedly fixed :)

    ReplyDelete
  2. Send this article to Sun.

    ReplyDelete
  3. Is there anyway to run code that isn't already installed on the computer? Or is it just a way to exploit more serious bugs in other software.

    ReplyDelete
  4. All the flaws mentioned in this post, with the exception of CVE-2010-0095, lead to arbitrary code execution.

    ReplyDelete
  5. Hopefully, Dalvik is immune to such issues :)

    ReplyDelete
  6. Sun doesn't exist anymore and they won't give a shit about it. IMHO we should avoid any java thing wiping it out from any computer

    ReplyDelete
  7. There is something I don't get about deserialization issues: if you create a subclass of the class being deserialized and override the readObject method, when the class is deserialized, MaliciousClass.readObject is put onto the stack, isn't it ? Therefore, why doesn't stack inspection prevent privileges elevation, MaliciousClass.readObject being before the doPrivileged call on the stack ?

    ReplyDelete
  8. For what it's worth, apparently its very common for the Sun Java team to require 2, 3 or even more iterations to properly fix a single security issue ...

    ReplyDelete