As you may already know, the past few months have been problematic to Oracle when it comes to security issues discovered in the popular and notorious Java browser plugin. The latest vulnerability that has been spotted to be exploited in the wild is CVE-2013-1493.
It has already been published that 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 interesting is the nature of this exploit. Most Java exploits from the past year or two used missing security checks in the Java source code in order to bypass Security Manager – the part in Java which is responsible to make sure that unsafe code (unsigned code written by 3rd parties) won't be able toper form certain operations which require elevated privileges. Other exploits used 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 the attacker to entirely nullify the Security Manager.
This is the kind of exploits which are usually found in browsers and other non-sandboxed applications, so it was a little bit of a surprise to see such techniques in Java code.
Prior to the memory corruption bug triggers, the exploit author first creates a bunch of imaging objects amongst them - two "Buffered Image" objects – a source object and a destination object, the source object will be filled with raster data.
[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, its job is to call the garbage collector (twice!) to free every last bit of heap memory and then, to reserve the entire JRE memory by filling the heap with meaningless data.
The "spray" method in this exploit share similarities with the "heap-spray" exploit delivery technique which is used in browsers, PDF and Flash, although we believe it's used prior to the memory corruption bug in order to control the JRE sensitive memory addresses (such as the security manager address :O).
When the spray method is done, we can see that the entire heap memory of the JVM is fully "occupied":
[image2: dump created by the JVM showing the heap has been exhausted]
Both "Buffered Image" objects (named "sbi" and "dbi") are then sent to the filter method, where the memory corruption vulnerability takes place.
The vulnerability itself resides in the built-in Java classes which allows for color conversion of in-memory images. These classes rely on the supplied image classes to provide information regarding how to convert the sRGB and CIEXYZ color representations. Fooling those classes may cause corruptions in the Java heap memory, which can later be used to get the addresses for the built-in classes and methods and override those.
As we all know, when an applet can control the security manager state, it is game-over for the entire java applet security architecture in our host, thus may allow the exploit author to create and run malicious files, download malwares and much more.
As usual, Trustwave SWG customers are protected against exploitation attempts of this vulnerability, without needing to install any security update.
The research and post were done by Dan Meged and Moshe Basanchig.