As you may already know, the past few months have beenproblematic to Oracle when it comes to security issues discovered in thepopular and notorious Java browser plugin. The latest vulnerability that hasbeen spotted to be exploited in the wild is CVE-2013-1493.
It has already been publishedthat CoolEK became the first exploit kit to add an exploit to CVE-2013-1493, soI won't bother you with the details of that. What's probably more interestingis the nature of this exploit. Most Java exploits from the past year or twoused missing security checks in the Java source code in order to bypassSecurityManager – the part in Java which is responsible to make sure thatunsafe code (unsigned code written by 3rd parties) won't be able toperform certain operations which require elevated privileges. Other exploitsused some type confusions or tricked the optimizer into doing the same thing.Yet, in our current case, a memory corruption bug was found which allows theattacker to entirely nullify the SecurityManager.
This is the kind of exploits which are usually found inbrowsers and other non-sandboxed applications, so it was a little bit of asurprise to see such techniques in Java code.
Prior to the memorycorruption bug triggers, the exploit author first creates a bunch of imagingobjects amongst them - two "BufferedImage" objects – a source object and adestination object, the source object will be filled with
[image1: code snippet showing the creation of the two image objects and the invocation of the color conversion method]
The exploit flow will later get to the "spray" method, itsjob is to call the garbage collector (twice!) to free every last bit of heapmemory and then, to reserve the entire JRE memory by filling the heap with meaninglessdata.
The "spray" method inthis exploit share similarities with the "heap-spray" exploit delivery techniquewhich is used in browsers, PDF and Flash, although we believe it's used priorto the memory corruption bug in order to control the JRE sensitive memoryaddresses (such as the security manager address :O).
When the spray method is done, we can see that the entireheap memory of the JVM is fully "occupied":
[image2: dump created by the JVM showing the heap has been exhausted]
Both "BufferedImage" objects (named "sbi" and "dbi") arethen sent to the filter method, where the memory corruption vulnerability takesplace.
The vulnerability itself resides in the built-in Javaclasses which allows for color conversion of in-memory images. These classes relyon the supplied image classes to provide information regarding how to convertthe sRGB and CIEXYZcolor representations. Fooling those classes may cause corruptions in the Javaheap memory, which can later be used to get the addresses for the built-inclasses and methods and override those.
As we all know, when an applet can control the securitymanager state, it is game-over for the entire java applet security architecturein our host, thus may allow the exploit author to create and run maliciousfiles, download malwares and much more.
As usual, Trustwave SWG customers are protected againstexploitation attempts of this vulnerability, without needing to install anysecurity update.
The research and post were done by Dan Meged and MosheBasanchig.