exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

Java Zero-Day Analysis

Java Zero-Day Analysis
Posted Jan 12, 2013
Authored by Adam Gowdiak | Site security-explorations.com

This write up documents an analysis of the current Java zero-day floating around that affects version 7 update 10.

tags | advisory, java
SHA-256 | 570d0ab91ce6ae4fe76761c04da03a7343f5d11d4f9bf2f3e155de151060f50c

Java Zero-Day Analysis

Change Mirror Download

Hello All,

We were notified today of ongoing attacks with the use of a new
Java vulnerability affecting latest version 7 Update 10 of the
software [1][2].

Due to the unpatched status of Issue 50 [3] and some inquiries
received regarding whether the attack code found exploited this
bug, we had a quick look at the exploit code found in the wild.
Below, we are providing you with the results of our analysis.

The 0-day attack code that was spotted in the wild today is yet
another instance of Java security vulnerabilities that stem from
insecure implementation of Reflection API [4].

The new attack is a combination of two vulnerabilities. The first
flaw allows to load arbitrary (restricted) classes by the means
of findClass method of com.sun.jmx.mbeanserver.MBeanInstantiator
class. This can be accomplished by the means of this code:

public static Class loadClass(String name) throws Throwable {
JmxMBeanServerBuilder jmxbsb=new JmxMBeanServerBuilder();
MBeanInstantiator mbi=jmxbs.getMBeanInstantiator();

return mbi.findClass(name,(ClassLoader)null);

The problem stems from insecure call to Class.forName() method.

The second issue abuses the new Reflection API to successfully
obtain and call MethodHandle objects that point to methods and
constructors of restricted classes. This second issue relies on
invokeWithArguments method call of java.lang.invoke.MethodHandle
class, which has been already a subject of a security problem
(Issue 32 that we reported to Oracle on Aug 31, 2012).

The company had released a fix for Issue 32 in Oct 2012. However,
it turns out that the fix was not complete as one can still abuse
invokeWithArguments method to setup calls to invokeExact method
with a trusted system class as a target method caller. This time
the call is however done to methods of new Reflection API (from
java.lang.invoke.* package), of which many rely on security checks
conducted against the caller of the target method.

Oracle's fix for Issue 32 relies on a binding of the MethodHandle
object to the caller of a target method / constructor if it denotes
a potentially dangerous Reflection API call. This binding has a
form of injecting extra stack frame from a caller's Class Loader
namespace into the call stack prior to issuing a security sensitive
method call. Calls to blacklisted Reflection APIs are detected with
the use of isCallerSensitive method of MethodHandleNatives class.
The blacklisting however focuses primarily on Core Reflection API
(Class.forName(), Class.getMethods(), etc.) and does not take into
account the possibility to use new Reflection API calls. As a result,
the invokeWithArguments trampoline used in the context of a system
(privileged) lookup object may still be abused for gaining access to
restricted classes, their methods, etc.

The above is important in the context of a security check that is
implemented by the Lookup class. Its checkSecurityManager method
compares the Class Loader (CL) namespace of the caller class of a
target find[*] method (findStatic, findVirtual, etc.) with the CL
namespace of a class for which a given find operation is conducted.
Access to restricted packages is not checked only if Class Loader
namespaces are equal (the case for public lookup object, but also
for a trusted method caller such as invokeWithArguments invoked for
not blacklisted method).

The exploit vector used by the attack code is the same as the one
we used for second instance of our Proof of Concept code for Issue
32 (reported to Oracle on 17-Sep-2012). This exploit vector relies
on sun.org.mozilla.javascript.internal.GeneratedClassLoader class
in order to define a fully privileged attacker's class in a system
Class Loader namespace. From that point all security checks can be
easily disabled.

This is not the first time Oracle fails to "sync" security of Core
and new Reflection APIs. Just to mention the Reflection API filter.

This is also not the first time Oracle's own investigation / analysis
of security issues turns out to be not sufficiently comprehensive.
Just to mention Issue 50, which was discovered in the code addressed
by the company not so long ago...

Bugs are like mushrooms, in many cases they can be found in a close
proximity to those already spotted. It looks Oracle either stopped
the picking too early or they are still deep in the woods...

Thank you.

Best Regards
Adam Gowdiak

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

[1] Malware don't need Coffee: 0 day 1.7u10 spotted in the Wild -
Disable Java Plugin NOW !

[2] New year, new Java zeroday!

[3] [SE-2012-01] Critical security issue affecting Java SE 5/6/7
[4] SE-2012-01 Details
Login or Register to add favorites

File Archive:

December 2022

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Dec 1st
    2 Files
  • 2
    Dec 2nd
    12 Files
  • 3
    Dec 3rd
    0 Files
  • 4
    Dec 4th
    0 Files
  • 5
    Dec 5th
    14 Files
  • 6
    Dec 6th
    18 Files
  • 7
    Dec 7th
    11 Files
  • 8
    Dec 8th
    45 Files
  • 9
    Dec 9th
    9 Files
  • 10
    Dec 10th
    0 Files
  • 11
    Dec 11th
    0 Files
  • 12
    Dec 12th
    0 Files
  • 13
    Dec 13th
    0 Files
  • 14
    Dec 14th
    0 Files
  • 15
    Dec 15th
    0 Files
  • 16
    Dec 16th
    0 Files
  • 17
    Dec 17th
    0 Files
  • 18
    Dec 18th
    0 Files
  • 19
    Dec 19th
    0 Files
  • 20
    Dec 20th
    0 Files
  • 21
    Dec 21st
    0 Files
  • 22
    Dec 22nd
    0 Files
  • 23
    Dec 23rd
    0 Files
  • 24
    Dec 24th
    0 Files
  • 25
    Dec 25th
    0 Files
  • 26
    Dec 26th
    0 Files
  • 27
    Dec 27th
    0 Files
  • 28
    Dec 28th
    0 Files
  • 29
    Dec 29th
    0 Files
  • 30
    Dec 30th
    0 Files
  • 31
    Dec 31st
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2022 Packet Storm. All rights reserved.

Hosting By