The Latest in IT Security

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


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.

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.

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.

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

Leave a reply



Mission-Critical Broadband – Why Governments Should Partner with Commercial Operators:
Many governments embrace mobile network operator (MNO) networks as ...

ARA at Scale: How to Choose a Solution That Grows With Your Needs:
Application release automation (ARA) tools enable best practices in...

The Multi-Model Database:
Part of the “new normal” where data and cloud applications are ...



Latest Comments