Jump to content
Nytro

An interesting case of JRE sandbox breach (CVE-2012-0507)

Recommended Posts

Posted

[h=3]An interesting case of JRE sandbox breach (CVE-2012-0507)[/h]

msft-mmpc 9k= msft-mmpc

9,745 Points 2 1 1

Recent Achievements

Blogger III Blogger II New Blog Rater

View Profile

20 Mar 2012 2:55 AM

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.

The vulnerability triggering class is actually performing deserialization of an object array and uses a vulnerability in the AtomicReferenceArray 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 CVE-2012-0507.

031312_1910_AnInteresti1.png

Figure 1 The vulnerability triggering class

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.

The 3rd 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 PWS:Win32/Zbot.gen!Y.

The following diagram shows the overall process of exploitation. A.class is the vulnerability triggering class, B.class is the loading class and C.class is the 3rd class that downloads, decodes and executes a malicious binary.

031312_1910_AnInteresti2.png

Figure 2 The overall view of exploitation

The following code shows the actual decoding code inside the C.class file. The routine is using a very simple form of XOR decoding.

031312_1910_AnInteresti3.png

Figure 3 Decoding routine inside C.class file

Example SHA1s:

fc1ab8bf716a5b3450701ca4b2545888a25398c9 (detected as Exploit:Java/CVE-2012-0507.A)

03e26e735b2f33b3b212bea5b27cbefb2af4ed34 (detected as Exploit:Java/CVE-2012-0507.B)

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 this patch update advisory page to see if you require any updates.

So please, update your JRE installations and protect yourself.

Jeong Wook (Matt) Oh & Chun Feng

Sursa: An interesting case of JRE sandbox breach (CVE-2012-0507) - Microsoft Malware Protection Center - Site Home - TechNet Blogs

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...