Tweet

Recently, security researchers disclosed two Java native layer exploits (CVE-2013-2465 and CVE-2013-2471). This caused us to look into native layer exploits more closely, as they have been becoming more common this year. At this year’s Pwn2Own competition at CanSecWest, Joshua Drake showed CVE-2013-1491, which was exploitable on Java 7 running on Windows 8. CVE-2013-1493 has become a popular vulnerability to target in exploits kits such as Blackhole.

To understand why these exploits are becoming more common, some understanding of Java’s architecture is helpful. Java exploits can be divided into two types: Java layer exploits and Java native layer exploits.

Figure 1. Java security model

The above graph shows the Java security model. Java layer exploits target vulnerabilities in the Java layer runtime, which lets applications bypass the Security Manager and call high privilege functions. These exploits have the following characteristics:

• Can be created with less effort, because attackers need not bypass operating system-level protections.
• Are cross-platform (i.e., work with multiple operating systems)

Similarly, Java native layer exploits target the Java native layer runtime. These exploits are harder to create, as they need to bypass OS-level protections like ASLR and DEP. In addition, the skills needed to create native layer exploits are more difficult to acquire.

Figure 2. Timeline of common Java vulnerabilities

In the past, Java layer vulnerabilities were more common, but that is no longer the case. Before 2013, there was a 3:1 ratio of Java layer vulnerabilities to Java native layer vulnerabilities. Starting this year, however, we are now seeing more native layer flaws. Why is this the case?

• A large amount of the vulnerabilities of are present in the Java native layer code. In the June 2013 Java SE Critical Patch Update Advisory, approximately half of all the vulnerabilities fixed were in the Java native layer code.
• Attackers are becoming more skillful in creating exploits. In the past, while there were many native layer vulnerabilities, less exploits were present because attackers did not always have the skill to create the necessary exploits.

This year, however, attackers clearly have the capability to take advantage of native layer vulnerabilities. Two methods of exploitation are becoming more common,

One is to make use of a Java array length overflow to tamper with the java.beans. Statement object’s AccessControlContext member. To do this, the following steps are necessary:

1. Prepare a Java Array object on a heap.

   

   Figure 3. Step #1

2. Trigger a Java native layer vulnerability. The array object’s length is overflowed to a very large value.

   

   Figure 4. Step #2

3. An attacker can then use the array object to get or set the following buffer precisely. They can tamper with the following java.beans.Statement object’s acc field, which points to a AccessControlContext object. In general, the acc field will be tampered to point to a full permission AccessControlContext object. This will let arbitrary code be run on the affected system.

   

   Figure 5. Step #3

This exploit method requires that both the buffer which can be used to trigger vulnerability and the buffer which needs to be overwritten are in the same heap. It requires some knowledge and skill to ensure that this is the case. In addition to this, information leaks and ROP shell code attacks were demonstrated at Pwn2Own 2013. It gets the module base address by targeting a Java native layer vulnerability and constructing ROP shell code to hijack the execution context. We believe that 2013 will see more similar exploits along these lines.

We urge users to carefully evaluate their usage of Java is necessary and ensure that copies of Java that are used are updated, to reduce exposure to present and future Java flaws.

Update as of 9:28 AM PDT, Sept. 2, 2013

Trend Micro Deep Security provides protection for threats targeting CVE-2013-2465, CVE-2012-4681, CVE-2012-1723 via the following rules:

• 1005598 – Identified Malicious Java JAR Files – 3
• 1004870 – Identified Suspicious Jar File
• 1005093 – Java Applet Field Bytecode Verifier Cache Remote Code Execution Vulnerability
• 1005640 – Oracle Java storeImageArray() Invalid Array Indexing Vulnerability