Message-ID: <516DC438.4050701@security-explorations.com>
Date: Tue, 16 Apr 2013 23:35:52 +0200
From: Security Explorations <contact@...urity-explorations.com>
To: bugtraq@...urityfocus.com, full-disclosure@...ts.grok.org.uk
Subject: [SE-2012-01] Details of issues fixed by Java SE 7 Update 21


Hello All,

Today, Oracle released Java SE 7 Update 21, which among other
things addresses six security vulnerabilities that were reported
to the company earlier this year (Issues 51, 55 and 57-60).

Our original vulnerability reports and Proof of Concept codes
for these and some previously disclosed issues (such as #50) are
available for download from the following location:

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

Additional comment to the published material is provided below.

[Issue 55]
This is a bug, which when combined together with published Issue
54 (judged by Oracle as the "allowed behavior" [1]) can be used
to completely break Java security sandbox.

Issue 55 is rather simple - it is about one API call that turns
arbitrary protected method handle (such as a defineClass method
of java.lang.ClassLoader) into an object that could be actually
called on behalf of a given Class Loader instances:

  ClassLoader cl=getClass().getClassLoader();
  defineClass_mh=defineClass_mh.bindTo(cl)

The problem with bindTo (and similar insertArguments) methods
implementation stemmed from the fact that they were missing a
security check verifying whether the first argument to the call
(this argument) was compatible with a type of a target method
handle (bound receiver type for protected methods).

[Issue 58]
This issue shows that new Reflection API and Method Handles in
particular can be very tricky in Java.

By design, it is possible to apply arbitrary transformations to
Method Handle objects such as binding, insertion or dropping of
given arguments. Among other things this can lead to the change
of a target Method Handle's type.

In our Proof of Concept Code, we convert a MethodHandle object
of "(SecurityManager)void" type to the "()void" type by creating
a new MethodHandle object that binds the SecurityManager argument
to the NULL value. This allows to use incompatible method handle
of "(SecurityManager)void" type where "()void" type is expected.

---

Additionally to the above mentioned issues, we decided to release
details of Issue 56 as well. This bug was reported to Oracle six
weeks ago. Although it was part of an exploit chain relying on 5
vulnerabilities in total (Issues 56-60) this issue has not been
confirmed by the company so far (other issues from the chain were
confirmed and should be addressed in Java SE 7 Update 21).

We believe that a complexity of the code provided to Oracle does
not judge a six weeks long evaluation of Issue 56:

   .method public <init>()V
   .limit stack 2
   .limit locals 2
   l1:
       goto l1
       return
   .end method

Java VM specification [2] and Bytecode Verifier's operation for
similar scenarios (no call to superclass or this) indicate that
the above code violates Java VM structural constraints.

Thank you.

Best Regards,
Adam Gowdiak

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

References:
[1] SE-2012-01 Press Info (4)
     http://www.security-explorations.com/en/SE-2012-01-press4.html
[2] The Java Virtual Machine Specification Java SE 7 Edition,
     4.9.2. Structural Constraints
 
http://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.9.2

Powered by blists - more mailing lists