Exploitation of Java Vulnerabilities
Java SE is a platform-independent programming language. It is used on all operating systems – Windows and *nix-based, which increases the scope of exploiting a security vulnerability in Java. I will examine two critical Java security vulnerabilities exploited in the wild during the last few months.
Applets in a sandbox
Java applets use a sandbox, which restricts them from accessing privileged operating system functionality and some privileged Java code. An applet developed by any programmer can therefore run safely in the browser without performing any malicious activities on the computer because applets are not permitted to do things like explicitly read or write from the file system or create network connections to external hosts. Attackers who exploit Java vulnerabilities escape the restrictions of the sandbox and are free to execute arbitrary code. This has potentially devastating effects on a computer.
Exploitation of Java security issues have, in recent years, increased significantly. Java exploits are more reliable because they do not need to bypass Windows security mechanisms such as Address Space Randomization Layout (ASLR) and Data Execution Prevention (DEP). The sole purpose of a Java vulnerability exploit is to bypass the applet sandbox restriction in order to download and execute malware.
Figure 1. Recent vulnerabilities patched
The above graph shows the number of Java Runtime Environment vulnerabilities fixed in the last two Oracle Java SE Critical Patch Updates (CPU).
Figure 2. Recent vulnerabilities timeline
In the last six months, there were two Java security vulnerabilities exploited in the wild due to a type-confusion error: Oracle Java SE Remote Java Runtime Environment Code Execution Vulnerability (CVE-2012-0507) and Oracle Java SE CVE-2012-1723 Remote Code Execution Vulnerability (CVE-2012-1723). Oracle had released the patches for both of these issues on Feb 14, 2012 and June 12, 2012 respectively. Technical details about both of these issues were published on the Internet about ten days after the release of the updates. It took more than a month to see attacks in the wild for CVE-2012-0507 after the update release while attacks for CVE-2012-1723 were detected in less than a month.
The CVE-2012-0507 vulnerability (Figure 3) occurs because the application fails to properly check if an array is of an expected Object type. The AtomicReferenceArray.set() method is used to write an arbitrary reference into the array and violates type safety.
Figure 3. CVE-2012-0507 code sample
The CVE-2012-1723 vulnerability (Figure 4) occurs because the Verifier fails to detect a PUTFIELD operation on a static field. The issue is described here and full technical details are also available in a Threat Analysis document for Symantec DeepSight customers.
Figure 4. CVE-2012-1723 code sample
Samples for both issues used the same technique for exploitation: the ClassLoader object obtained through getClass().getClassLoader() utilizing the type confusion vulnerability to create confusion with a subclass of ClassLoader. The protected method defineClass() of ClassLoader is called to dynamically create a new class with new permissions.
Figure 5. Creation of new class and permissions
Under normal circumstances the above process is not allowed in the sandbox.
Figure 6. Exploitation utilizing type confusion vulnerability
The next scheduled Oracle Java SE Critical Patch Update is October 16, 2012 and we recommend users apply Java updates as soon as they become available.
Symantec detects exploit attempts for CVE-2012-1723 as Trojan.Maljava!gen23 along with "Web Attack: Malicious JAR Download 2" and "Malicious JAR Download" IPS detections. CVE-2012-0507 exploit attempts are detected by "Web Attack: JRE Concurrency CVE-2012-0507" IPS detection.