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:

http://www.security-explorations.com/en/SE-2012-01-details.html

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
http://www.security-explorations.com
"We bring security research to the new level"
---------------------------------------------

References:

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