An interesting case of JRE sandbox breach (CVE-2012-0507)<p>Recently we received a few samples that exploit the latest patched JRE (Java Runtime Environment) vulnerability. These samples are kind of unusual to see, but they can be used to develop highly reliable exploits. The malicious Java applet is loaded from an obfuscated HTML file. The Java applet contains two Java class files - one Java class file triggers the vulnerability and the other one is a loader class used for loading.</p>
<p>The vulnerability triggering class is actually performing deserialization of an object array and uses a vulnerability in the <em>AtomicReferenceArray</em> to disarm the JRE sandbox mechanism. The attacker deliberately crafted serialized object data. This reference array issue is very serious since the exploit is not a memory corruption issue, but a logical flaw in the handling of the array. So the exploit is highly reliable and that might be one of the reasons why the bad guys picked up this vulnerability for their attacks. We determined this vulnerability to be <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0507">CVE-2012-0507</a><span>. </span></p>
<p><img alt="" src="http://www.microsoft.com/security/portal/blog-images/JRE/031312_1910_AnInteresti1.png" /></p>
<p>Figure 1 The vulnerability triggering class</p>
<p><br />The loader class is called from the vulnerability triggering class. This loader class can load additional classes in an escalated privilege context and perform any operations escaping the sandbox mechanism. This loader class creates a new class on the fly and uses it to do malicious jobs with escalated privileges.</p>
<p>The 3<sup>rd</sup> class that is loaded by the loader class downloads a malicious file and decodes it using a simple XOR algorithm. It saves it into a local temporary folder and executes the file using Runtime's exec method. The decoded malicious file is detected as <a href="http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?Name=PWS:Win32/Zbot.gen!Y">PWS:Win32/Zbot.gen!Y</a>.</p>
<p>The following diagram shows the overall process of exploitation. <em>A.class </em>is the vulnerability triggering class, <em>B.class</em> is the loading class and <em>C.class</em> is the 3<sup>rd</sup> class that downloads, decodes and executes a malicious binary.</p>
<p><img alt="" src="http://www.microsoft.com/security/portal/blog-images/JRE/031312_1910_AnInteresti2.png" /></p>
<p>Figure 2 The overall view of exploitation</p>
<p>The following code shows the actual decoding code inside the <em>C.class</em> file. The routine is using a very simple form of XOR decoding.</p>
<p><img style="width: 640px; height: 173px;" alt="" src="http://www.microsoft.com/security/portal/blog-images/JRE/031312_1910_AnInteresti3.png" /></p>
<p>Figure 3 Decoding routine inside C.class file</p>
<p>Example SHA1s:</p>
<p>fc1ab8bf716a5b3450701ca4b2545888a25398c9 (detected as Exploit:Java/CVE-2012-0507.A)<br />03e26e735b2f33b3b212bea5b27cbefb2af4ed34 (detected as Exploit:Java/CVE-2012-0507.B)</p>
<p>The good news is that the vendor has provided a patch for this vulnerability since late February. Just make sure you have the latest JRE version installed on your system. Or you can visit <a href="http://www.oracle.com/technetwork/topics/security/javacpufeb2012-366318.html">this patch update advisory page</a> to see if you require any updates.</p>
<p>So please, update your JRE installations and protect yourself.</p>
<p><em>Jeong Wook (Matt) Oh & Chun Feng</em></p><div style="clear:both;"></div><img src="http://blogs.technet.com/aggbug.aspx?PostID=3487643" width="1" height="1">
Source:
An interesting case of JRE sandbox breach (CVE-2012-0507)
