Hello All,

Below, we are providing you with technical details regarding
security issues reported by us to Oracle and addressed by the
company in a recent Feb 2013 Java SE CPU [1].

[Issue 29]
This issue allows for the creation of arbitrary Proxy objects
for interfaces defined in restricted packages. Proxy objects
defined in a NULL class loader namespaces are of a particular
interest here. Such objects can be used to manipulate instances
of certain restricted classes.

In our Proof of Concept code we create such a proxy object for
the com.sun.xml.internal.bind.v2.model.nav.Navigator interface.
In order to use the aforementioned proxy object, we need an
instance of that interface too. We obtain it with the help of
Issue 28, which allows to access arbitrary field objects from
restricted classes and interfaces. As a result, by combining
Issue 27-29, one can use Navigator interface and make use of
its sensitive Reflection API functionality such as obtaining
access to methods of arbitrary classes. That condition can be
further leveraged to obtain a complete JVM security bypass.

Please, note that our Proof of Concept code for Issues 27-29
was reported to Oracle in Apr 2012 and depending Issues 27-28
were addressed by the company sooner than Issue 29. Testing
of the PoC will thus give best results on older versions of
Java SE 7.

[Issue 50]
Issue 50 allows to violate a fundamental security constraint
of Java VM, which is type safety. This vulnerability is another
instance of the problem related to the unsafe deserialization
implemented by com.sun.corba.se.impl.io.ObjectStreamClass class.
Its first instance was fixed by Oracle in Oct 2011 [2] and it
stemmed from the fact that during deserialization insufficient
type checks were done with respect to object references that
were written to target object instance created by the means of
deserialization. Such a reference writing was accomplished with
the use of a native functionality of sun.corba.Bridge class.

The problem that we found back in Sep 2012 was very similar to
the first one. It was located in the same code (class) and was
also exploiting direct writing of object references to memory
with the use of putObject method. While the first type confusion
issue allowed to write object references of incompatible types
to correct field offsets, Issue 50 relied on the possibility to
write object references of incompatible types to...invalid field
offsets.

It might be also worth to mention that Issue 50 was found to
be present in Java SE Embedded [3]. That is Java version that
is based on desktop Java SE and is used in today’s most powerful
embedded systems such as aircraft and medical systems [4]. We
verified that Oracle Java SE Embedded ver. 7 Update 6 from 10
Aug 2012 for ARM / Linux contained vulnerable implementation
of ObjectStreamClass class.

Unfortunately, we don't know any details regarding the impact
of Issue 50 in the embedded space (which embedded systems are
vulnerable to it, whether any feasible attack vectors exist,
etc.). So, it's up to Oracle to clarify any potential concerns
in that area.

[Issue 52]
Issue 52 relies on the possibility to call no-argument methods
on arbitrary objects or classes. The vulnerability has its origin
in com.sun.jmx.mbeanserver.Introspector class which is located
in the same package as the infamous MBeanInstantiator bug found
in the wild in early Jan 2013. The flaw stems from insecure call
to invoke method of java.lang.reflect.Method class:

         if (method != null)
               return method.invoke(obj, new Object[0]);

In our Proof of Concept code we exploit the above implementation
by making a call to getDeclaredMethods method of java.lang.Class
class to gain access to methods of restricted classes. This is
accomplished with the use of the following code sequence:

Introspector.elementFromComplex((Object)clazz,"declaredMethods")

Access to public method objects of arbitrary restricted classes
is sufficient to achieve a complete Java VM security sandbox
compromise. We make use of DefiningClassLoader exploit vector
for that purpose.

[Issue 53]
Issue 53 stems from the fact that Oracle's implementation of new
security levels introduced by the company in Java SE 7 Update 10
did not take into account the fact that Applets can be instantiated
with the use of serialization. Such a possibility is indicated both
in HTML 4 Specification [5] as well as in Oracle's code.

HTML 4 Specification contains the following description for the
"object" attribute of APPLET element:

object = cdata [CS]
        This attribute names a resource containing a serialized
        representation of an applet's state. It is interpreted
        relative to the applet's codebase. The serialized data
        contains the applet's class name but not the implementation.
        The class name is used to retrieve the implementation from
        a class file or archive.

Additionally, Java 7 Update 10 (and 11) reveal the following code
logic when it comes to the implementation of new security features
(Java Control Panel security levels).

[excerpt from sun.plugin2.applet.Plugin2Manager class]

         String object_attr = getSerializedObject();
         String code_attr   = getCode();
         ...

         if(code_attr != null) {
             Class class1 = plugin2classloader.loadCode(code_attr);
             ...
             if(class1 != null)

                 if (fireAppletSSVValidation())
                 ...
         } else {
             if(!isSecureVM)
                 return;
 
adapter.instantiateSerialApplet(plugin2classloader,object_attr);
             ...
         }

The above clearly shows that the conditional block implementing
Applet instantiation via deserialization does not contain a call
to fireAppletSSVValidation method. This method conducts important
security checks corresponding to security levels configured by
Java Control Panel. The lack of a call to security checking method
is equivalent to "no protection at all" as it allows for a silent
Java exploit in particular.

What's worth mentioning is that for Google Chrome the following
HTML sequence needed to be used to activate target Applet code:

<object type="application/x-java-applet" object="BlackBox.ser">

---

We have made our original reports sent to Oracle and describing
Issues 29, 50, 52 and 53 available for download from our project
details page:

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

Along with those reports we have also published the results of
our quick Vulnerability Fix Experiment regarding Issue 50. We've
never heard a word from Oracle regarding it. Company's fix for
Issue 50 is not a mirror of the one we had proposed, but it does
rely on Class object instances for hashtable access / caching of
translated ObjectStreamClass fields.

At the end, we would like to question Oracle's evaluation of the
impact of Java vulnerabilities fixed by the Feb 2013 Java SE CPU.
Oracle emphasized that patched vulnerabilities affect primarily
Java Plugin / desktop environments and that only 3 of them apply
to client and server deployments of Java. The 3 vulnerabilities
Oracle refers to are specifically the following ones:

CVE-2013-0437 Subcomponent 2D
CVE-2013-1478 Subcomponent 2D
CVE-2013-1480 Subcomponent AWT

None of the vulnerabilities above seem to refer to the components
where our discoveries were made (i.e. CORBA, JMX / BEANS).

The tests we have conducted yesterday against the latest version
of Oracle GlassFish Server 3.1.2.2 (with security manager enabled)
and RMI Registry from JDK 7 Update 11 confirmed the possibility to
launch an attack against remote RMI server with the use of a Java
SE vulnerability. We tested Issues patched by the recent CPU such
as the MBeanInstantiator bug, Issue 50 and 52 and were able to:
1) remotely load custom classes into the target Java RMI server
    (over RMI protocol),
2) completely break Java security sandbox with the use of a Java
    SE vulnerability (the one which "can be exploited only through
    untrusted Java Web Start applications / untrusted Java applets"
    according to Oracle's CPU).

Although Oracle is aware [6] that Java SE vulnerabilities can be
also exploited "in servers, by supplying malicious input to APIs
in the vulnerable server component", the company rather undermines
such a possibility by delivering a message that a majority of the
vulnerabilities affect Java Plugin in the web browser or that in
some cases, the exploitation scenario of Java SE bugs on servers
is very improbable.

In general, relying on a vulnerable Java SE version makes all of
the products depending on it potentially vulnerable unless there
is absolutely *no way* that a vulnerable component can be reached
by an attacker. As long as an attack vector through RMI protocol
is valid, a potential for remote exploitation of security issues
in Java SE on servers should be always concerned.

Thank You.

Best Regards,
Adam Gowdiak

---------------------------------------------
Security Explorations
http://www.security-explorations.com
"We bring security research to the new level"
---------------------------------------------

References:
[1] Oracle Java SE Critical Patch Update Advisory - February 2013
 
http://www.oracle.com/technetwork/topics/security/javacpufeb2013-1841061.html
[2] Oracle Java IIOP Deserialization Type Confusion Remote Code 
Execution Vulnerability
     http://www.zerodayinitiative.com/advisories/ZDI-11-306/
[3] Oracle Java SE Embedded
 
http://www.oracle.com/us/technologies/java/embedded/standard-edition/overview/index.html
[4] Oracle making embedded Java push
 
http://www.infoworld.com/d/application-development/oracle-making-embedded-java-push-203168
[5] HTML 4 Specification, Including an applet: the APPLET element
     http://www.w3.org/TR/html401/struct/objects.html#h-13.4
[6] February 2013 Critical Patch Update for Java SE Released
 
https://blogs.oracle.com/security/entry/february_2013_critical_patch_update