CVE-2012-4681 - Oracle Java 7 Vulnerability Analysis [Oracle 1.6.0_34 seems to be safe]

FYI

0-day exploit CVE-2012-4681

http://www.deependresearch.org/2012/08/java-7-vulnerability-analysis.html
http://pastie.org/4594319

Culprit is the public accessible sun.awt.SunToolkit.getField(Class, String) method:
  <http://www.docjar.com/html/api/sun/awt/SunToolkit.java.html#301>
it sets the queried field accessible and hence can be written to later on.

This vulnerability is being used to set the SecurityManager to null.

+++

In detail:

(*) The actual vulnerability here ..

[1] Access java.beans.Statement's AccessControlContext field "acc" and get write access (*)

    "java.beans.Statement { private final java.security.AccessControlContext acc; }"

    - Is being read via sun.awt.SunToolkit.getField(Class, String)
    - The latter executes w/ all permissions, i.e. "AccessController.doPrivileged(new PrivilegedAction<Field>() { .. }"
    - The latter does a "field.setAccessible(true);"
    - This leaves the field accessible (*)


[2] Patch the AccessControlContext field "acc" of an java.beans.Statement instance

  "Statement localStatement = new Statement(System.class, "setSecurityManager", new Object[1]);"

  - A local AccessControlContext localControlContext is being created
    w/ AllPermissions and local file access w/o any certificates.

  - This localStatement "acc" field (as retrieved and vulnerable by [1])
    is now being set w/ our own localControlContext


[3] Execution of Statement localStatement ..
  - localStatement.execute() executes the statement while performing:
        return AccessController.doPrivileged(
                    new PrivilegedExceptionAction<Object>() {
                        public Object run() throws Exception {
                            return invokeInternal();
                        } }, acc );
    this elevates the AccessControlContext "acc" w/ AllPermissions (patched w/ [2])
    on top of the AccessController stack and will also be used
    to validate the actual call to "java.lang.System.setSecurityManager(SecurityManager)"

  - java.lang.System.setSecurityManager(SecurityManager) is being called
    and replaces the SecurityManager w/ null

[4] No more SecurityManager is installed ..

+++

sun.awt.SunToolkit.getField(Class, String) is not public nor accessible in Java 1.6,
and hence this vulnerability does not work there ..

+++

Before releasing RC11, we will audit our code base for vulnerabilities.
This task has been piled up for a while .. sorry.

+++

~Sven

Mozilla wants to block Java in Firefox 18. The final users will probably get a scary warning message discouraging him to run Java applications like with Chrome. I was right, they are trying to kill Java.

Nice followup of the same issue, re-surfaced last week:
http://seclists.org/bugtraq/2013/Jan/48

[SECURITY] IcedTea 2.1.4, 2.2.4 & 2.3.4 Released!
http://blog.fuseyism.com/index.php/2013/01/15/security-icedtea-2-1-4-2-2-4-2-3-4-released/
    S8004933, CVE-2012-3174: Improve MethodHandle interaction with libraries
    S8006017, CVE-2013-0422: Improve lookup resolutions
    S8006125: Update MethodHandles library interactions

This update includes the OpenJDK 7 fixes for the recent 0-day.