the original cloud security

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
MD5 | 75157e6c0a4bcad5377103da79c44620

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();
JmxMBeanServer
jmxbs=(JmxMBeanServer)jmxbsb.newMBeanServer("",null,null);
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
http://www.security-explorations.com
"We bring security research to the new level"
---------------------------------------------

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

http://malware.dontneedcoffee.com/2013/01/0-day-17u10-spotted-in-while-disable.html
[2] New year, new Java zeroday!

http://labs.alienvault.com/labs/index.php/2013/new-year-new-java-zeroday/
[3] [SE-2012-01] Critical security issue affecting Java SE 5/6/7
http://seclists.org/fulldisclosure/2012/Sep/170
[4] SE-2012-01 Details
http://www.security-explorations.com/en/SE-2012-01-details.html

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

July 2017

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

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2016 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close