[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[SE-2012-01] Issue 69 details and IBM Java vulnerabilities

Hello All,

The CPU released yesterday (Oct 15, 2013) by Oracle included information
about a fix for Java SE 7 vulnerability (Issue 69) that was reported to
the company in July.

Issue 69 allows to conduct a very classic attack against Java VM - the so
called class spoofing attack. To quote the paper from 2002 [1] (5.2 Class
Loader attack / class spoofing paragraph):

"Protection of Class Loader objects is one of the key aspects of the Java
Virtual Machine security. This is due to the role Class Loaders play in
the process of class loading and dynamic linking. Class Loaders are primarily
responsible for providing JVM with classes’ definitions. When doing this,
Class Loaders always make sure that a given class file is loaded into Java
Runtime only once by a given Class Loader instance. Additionally, they make
sure that there exists only one and unique class file for a given class name.
These two requirements are maintained in order to provide proper separation
of namespaces belonging to different Class Loader objects. [...] for each
instance of Class Loader object, separate namespace is maintained. Each such
namespace contains a unique set of classes that were loaded by a given Class
Loader instance. Because of the possibility that two different Class Loader
objects can exist in one JVM, proper maintenance of their namespaces is
critical to the overall JVM security. This is primarily due to the fact that
any overlapping of two different namespaces can easily lead to class spoofing
and as a result, to type confusion attack."

Issue 69 allows to violate the security constraints imposed on Class Loaders
that guard their namespaces. This is due to new Reflection API and the way it
was implemented at the core VM level.

With new Reflection API, Method Handles got introduced to Java as a form of
arbitrary code execution transfer.

Additional quote from same abovementioned paper states the following:

"There exist at least two other theoretical variants, which could be used to
conduct class spoofing attack without implicit use (and overriding) of the Class
Loader’s loadClass method. Both of these attacks are based upon the idea of
spoofing class definitions at the point in a Java program when code execution is transferred from one namespace to the other. In Java, such execution transfer can be done with the use of exceptions and virtual methods. In the first case, an attack variant known as Princeton Class Loader attack was identified in the
past. This attack was based upon the fact that exceptions could be thrown in
one namespace and caught in the other. As a result, a definition of a subclass
of java.lang.Throwable class could be spoofed and confused along different
namespaces. In the second variant of the class spoofing attack, an arbitrary
hierarchy of classes is created. This hierarchy contains the classes that come
from different namespaces and that define the same virtual method. Upon the
invocation of the virtual method done from one namespace, a call to its overridden instance in the class defined in the other namespace could be theoretically done. Consequently, some arbitrary types of the method’s arguments could be confused
as they could be defined differently in different namespaces."

Our class spoofing attack relies on the possibility to transfer code execution from one Class Loader namespace to the other one by the means of Method Handles. The transfer is done across a method signature that has a different definition for a given named type in both Class Loader namespaces. Thus, class spoofing.

In normal circumstances, presence of conflicting class names (spoofed classes) in a method signature should be caught by Java VM. This was not the case for new Reflection API and Method Handle based calls done across Class Loader namespaces.

Actual details and a Proof of Concept code illustrating the described vulnerability
and class spoofing attack are available at the following address:


Due to the fact that in Sep 2013 Oracle backported (from JDK 8) implementation of the affected component to JDK 7 Update 40, the POC code will only work on Java SE
7 Update 25 and below.


As for other things, we would also like to report that a new vulnerability notice was sent to IBM today. It included information and Proof of Concept codes for two new complete Java sandbox escape vulnerabilities affecting IBM SDK, Java Technology Edition, Version 7.0 SR5 (Linux 32-bit x86 build pxi3270sr5-20130619_01 SR5 tested).

Apart from that we also pointed out to IBM that one of the issues originally reported to the company in Sep 2012 has not been fixed properly. The patch for it (the second attempt to address it) can be still successfully bypassed. As a result, complete Java security sandbox escape can be gained in the environment of vulnerable IBM Java SDK.

Thank you.

Best Regards
Adam Gowdiak

Security Explorations
"We bring security research to the new level"


[1] Java and Java VM security vulnerabilities and their exploitation techniques,
    Last Stage of Delirium Research Group, http://lsd-pl.net/