Recently, a 0-day vulnerability (CVE-2013-0422) was disclosed. Oracle promptly reacted on this 0-day vulnerability, and last weekend a new patch was made available. Here’s the advisory from Oracle. You can download latest JRE here. As the vulnerability is specific to Java 7, if you’re using JRE 7, you should apply the patch.
From our analysis, we’ve seen that it is a package access check issue which allows the untrusted Java applet to access the restricted class in trusted code. Using a vulnerable class and method, the exploit can find and load an internal class that is used to load the attacker’s own class with elevated privilege. The payload will disable security manager, and drop and run executable on the user’s system.
The problem lies in the MethodHandle feature that was introduced with Java 7. This feature is used to add better support for the dynamic language that works on JVM and gives flexible and faster way to access classes and methods in dynamic way. The MethodHandle feature can be used to create a handle for a method from an arbitrary class.
Every method handle will go through security check when they are first resolved. If you’re using the MethodHandle feature as it is intended, there will not be a security issue. The interesting fact is that you can create MethodHandles for classes from the MethodHandles package itself. The method handle created from some methods of MethodHandles Lookup class (java.lang.invoke.MethodHandles.Lookup class) itself has some problems in this perspective. MethodHandles Lookup class provides a way to lookup the constructor and methods from the target class where it tries to make a handle. For example, if the methods handle for findConstructor method of MethodHandles Lookup class is used to resolve a constructor method for an arbitrary class, the security check will not be enforced correctly. This can be an issue, if the target class is from a trusted code area, and it provides way to construct a user-defined class on the fly with arbitrary security context.
The payload class executes a dropped executable on the user’s system. As the vulnerability is more of an access check logic issue, the exploitation isn’t dependent on the platform and memory layout of the user’s machine. The exploitation success rate is very high compared to exploitation on memory corruption vulnerabilities if the user is using vulnerable software.
The first exploit was seen in late December 2012, and it showed very low activity during the time. However, since the public disclosure happened a few days ago, the samples and telemetry are increasing drastically, almost catching up with previous major Java vulnerabilities (CVE-2012-4681, CVE-2012-5076). The one notable thing is that we’ve started seeing multi-exploit samples combining CVE-2013-0422 and CVE-2012-1723. For example, a sample (SHA1: 5865004f90607f168f698984299a1ca8efbe0e07) was found to combine both exploits in one package. The strategy of this combined exploit is that by sending one exploit code, they can cover any vulnerable Java 6 installations (up to JRE 6u32) and vulnerable Java 7 installations (up to JRE 7u10) at one time. As for JRE 7, CVE-2012-1723 is only applicable up to JRE 7u4, they can abuse CVE-2013-0422 to cover JRE 7u5 to 7u10 for exploitation.
We detect this threat as Exploit:Java/CVE-2013-0422, and definition files from 1.141.3637.0 will thwart this threat. As we said, Java malware shows a high success rate in exploitation when you don’t use up-to-date JRE, so we strongly advise you to update your JRE immediately to be protected from these Java malware.
Jeong Wook (Matt) Oh
