Symantec on ZDI-10-051 and ZDI-10-056

An interesting piece on the Symantec blog by Adrian Pisarczyk on ZDI-10-051 (CVE-2010-0094) and ZDI-10-056 (CVE-2010-0840).

"Perfect" Client-Side Vulnerabilities

The first property, which makes such issues attractive for attackers, stems from the fact that they do not rely on any memory-corruption conditions; hence, the exploits are extremely reliable and do not have to cope with memory protection mechanisms. ASLR and DEP-based protections will not protect against the exploits.

...

Another uncommon vulnerability feature sought after by attackers is platform and browser independence.

Not to take absolutely anything away from it, but Adrian's analysis makes much of the same, valid points as Julien Tinnes' post from about a year back on the calendar deserialization issue:

Write Once, Own Everyone

...most other client-side vulnerabilities that can lead to arbitrary code execution, including other Java vulnerabilities are memory corruption vulnerabilities in a component written in native code. Exploiting those reliably can be hard. Especially if you have to deal with multiple operating system versions or with PaX-like protections such as DEP and ASLR.
This one is a pure Java vulnerability. This means you can write a 100% reliable exploit in pure Java. This exploit will work on all the platforms, all the architectures and all the browsers!

Pwnie Nomination (Pwnie for Best Client-Side Bug)

The CVE-2008-5353 (Java Calendar Object Deserialization Sandbox Privilege Escalation) got nominated for a Pwnie award in the 2009 category for the Best Client-Side Bug with the credits going to Julien Tinnes and yours truly.

http://pwnie-awards.org/2009/nominees.html#bestclientbug

Update: The Pwnie for Best Client-Side bug went to Ryan Smith for the msvidctl.dll MPEG2TuneRequest Stack buffer overflow (CVE-2008-0015)

WORA? WOOE.

WORA? WOOE. An interesting bit by Julien Tinnes on the calendar deserialization bug, Java applet security in general and Apple taking a long time to fix it on OSX.

Landon Fuller has a Proof of Concept implementation to demonstrate the problem.

Correction on how Sun fixed the Calendar bug

Many thanks to Julien Tinnes for pointing this out to me.

In a previous post, I had said:

What they did fix, and on this I fully agree is that now when a serializable subclass of a non-serializable class is deserialized, a generated sun.reflect.GeneratedSerializationConstructorAccessorxxx instance is put on the call stack before calling the superclass constructor, thus making it lose the privileged context in the case where the subclass itself isn't privileged.

Which is obviously silly and not true at all. When I was looking at how Sun had fixed the problem I had obtained an incorrect source for the new Calendar class and that threw me off the track. The GeneratedSerializationConstructorAccessorxxx was always on the stack, it's the means of invoking the superclass constructor. What changed is that the calling context is not so privileged anymore in the case of the Calendar.readObject(). A special AccessControlContext is created with just enough special rights to access the package sun.util.calendar, which normally isn't accessible to applet code. But if your serialized class tries to do something more (like instantiating a ClassLoader) a security exception is thrown.