BRIEF INTRO:
Oracle Java versions prior to 7u25 suffer from an invalid array indexing vulnerability that exists within the native storeImageArray() function inside jre/bin/awt.dll. This vulnerability allows for remote code execution. User interaction is required for this exploit in that the target must visit a malicious page or open a malicious file.
BACKGROUND:
We observed that a Java native code vulnerability has been actively exploited, and we have been able to reproduce the attack in–house with Java 7 update 25 on Windows. Today the sample I share to you is not a wild exploit sample but a POC which will launch calculator on your machine by exploiting the vulnerability.
ATTACK FLOW:
The POC disables security manager by exploiting invalid array indexing vulnerability in function storeImageArray, and then execute arbitrary code.
Firstly, the POC initializes an integer array and an object array which contains powerful AccessControlContext with all permission and one Statement to set security manager; then, exploit the vulnerability to cause integer overflow, make it possible to visit following stack block by the index of integer array; following, overwrite Statement’s private field AccessControlContext with powerful AccessControlContext; at last, use all permission Statement to set security manger to NULL, execute arbitrary code. Following are detailed steps:
1. Initialize an integer array contains 8 integers whose length will be overwritten to 0xffffffff at last;
2. Initialize an object array contains 7 objects, this object array is only been initialized with 3 elements -- index 2, 3 and 4. You can see from following figure that array[2] is a Statement with class System, method SetSecurityManager and parameter NULL; array[3] is a powerful AccessControlContext used to overwrite Statement.acc later; array[4] is System.class;
3. Vulnerability exploit to cause Integer overflow(this part will be described in detail in next section EXPLOIT POINT);
4. After exploiting successfully, the POC can access following stack block by index of array a initialized in step 1.
5. Overwrite default Statement.acc to powerful AccessControlContext(AllPermission). Since exploiting successfully, POC can look for System.class in stack via index of array a. once found, call the index of System.class X, then a[X-1] is Statement.acc, overwrite this field to powerful AccessControlContext which has been initialized in step 2;
6. Since Statement.acc has been overwritten to a powerful AccessControlContext, now POC has the ability to disable security manager.
7. After security manager been bypassed, just execute arbitrary code(payload).
EXPLOIT POINT:
The invalid array indexing vulnerability exists within the native function storeImageArray inside jre/bin/awt.dll.
The "dataP" pointer can be taken from "data" field of the "sun.awt.image.BytePackedRaster" Java object. The "hintP->dataOffset" value is taken from the "dataBitOffset" field.
While BytePackedRaster cannot be accessed directly, but can be created via the public java.awt.image.Raster.createWritableRaster() method.
The first parameter of "createWritableRaster()" is "java.awt.image.SampleModel". The sample model object should be java.awt.image.MultiPixelPackedSampleModel in order to create BytePackedRaster.
MultiPixelPackedSampleModel accepts dataBitOffset parameter without any checks.
BytePackedRaster() constructor calculates the dataBitOffset value basing on SampleModel and DataBuffer parameters.
Function verify() is called in the last of constructor BytePackedRaster(), which allows you to set "dataBitOffset" almost eight times bigger than "data.length". So, "dataBitOffset" can point outside the "data" array and this is enough to cause the memory corruption inside the native storeImageArray() function.
Back to this POC, when call function createWritableRaster() , the first parameter is an instance of MultiPixelPackedSampleModel with a large field dataBitOffset(size 52), the second parameter is an instance of DataBufferByte with size 16. Then AffineTransformOp.filter(BufferedImage1, BufferedImage2), BufferedImage1 is a regular instance of BufferedImage while BufferedImage2 is a carefully constructed instance of BufferedImage. This kind of calling will trigger the vulnerability be exploited.
If you want to ask why call AffineTransformOp.filter(BufferedImage1, BufferedImage2) will trigger the exploit, let me show you this:
By setting breakpoint at native function storeImageArray() , we can see the call stack to storeImageArray(). You can see Java_sun_awt_image_ImagingLib_transformBI() called storeImageArray().
And, from IDE’s perspective, we can see the call stack as follows is:
MyJApplet.tryExpl() à AffineTransformOp.filter(…) à ImagingLib.filter(…)
Then, ImagingLib.filter() will call transformBI(…)
So, as a conclusion, you can see the whole call stack from POC entry to exploit point storeImageArray() is:
POC à MyJApplet.tryExpl() à AffineTransformOp.filter(…) à ImagingLib.filter(…) à ImagingLib.transormBI(…) à storeImageArray()
The good news is that the vendor has provided a patch for this vulnerability since June 18th, year 2013. Just make sure you have the latest JRE version installed on your system. Or you can visit this page to see if you require any updates.
So please, update your JRE installations and protect yourself.
