Defeating the Same Origin Policy part 2

Defeating the Same Origin Policy part 2

Summary: In my first post in this series, I discussed the Same Origin Policy and how it protects us from some very serious attacks, the dangers of domain name based trust, and how to attack implementations of the Same Origin Policy within the Java Virtual Machine (JVM).  In order to demonstrate these concepts, I used two examples of real-world attacks against the Same Origin Policy implementation within the JVM.

SHARE:

Billy RiosIn my first post in this series, I discussed the Same Origin Policy and how it protects us from some very serious attacks, the dangers of domain name based trust, and how to attack implementations of the Same Origin Policy within the Java Virtual Machine (JVM).  In order to demonstrate these concepts, I used two examples of real-world attacks against the Same Origin Policy implementation within the JVM.  The first example was of an attack that Billy Rios (pictured above) and I first presented at Hack In the Box Malaysia in 2007.  We’re going to skip over the details of this attack, but if you want to see more on it view my previous post in this series, as well as an article I posted on Billy’s XS-Sniper blog.  What’s important to recognize is what the attack accomplished.  Using this attack, Billy and I were able to create an attack applet that would use anti-DNS pinning to allow it to reach internal Oracle database servers, brute force an account on the Oracle database server, and then allow interactive arbitrary SQL operations to be performed on the database server.  What’s important to note about this attack, is that while it is interesting and very dangerous, it is not a direct compromise.

John HeasmanThe second example that I used came from John Heasman (pictured to the right), and it is another anti-DNS pinning attack that this time utilized the code and codebase parameters of the <APPLET> HTML element to cause the bypass.  In this attack, Heasman loads code from the location specified by the “code” parameter, but convinces the JVM that it was loaded from the location specified by the “codebase” parameter.  What was specifically interesting about this attack and deserves a revisit, is that Heasman discovered that this same flaw could be used to break out of the Java sandbox and allow an attacker to directly compromise the victim’s underlying operating system.  I’ve paraphrased Heasman’s latest blog posting below so that we can discuss:

Extensions in Java are groups of packages and classes that augment the runtime classes. Extensions are installed into a specified directory and consequently can be located via the JRE without having to explicitly name them on the class path. QuickTime for Java is an example of a Java extension; once installed it enables Java applications to play QuickTime media (and yes, its had its share of security issues).

Moving on... take a look in your java.policy file (located in java.home\lib\security\java.policy) and you'll see where this attack is going. The first entry is most likely:

// Standard extensions get all permissions by default grant codeBase "file:${{java.ext.dirs}}/*" {         permission java.security.AllPermission; };

Rob CarterWow, ok, that’s really interesting.  Look closely at the java.policy code and you can see that there is a URI/Protocol handler there, the file:// protocol handler.  Rios, Rob Carter (pictured to the right), and I have been leading a year-long charge at uncovering URI/Protocol handler issues, and one thing we’ve continuously discussed is the potential for application functionality abuse through this protocol handlers.  This is a perfect example of this, and I wanted to call special attention to this, as one of my future posts in this series will discuss just this type of issue, highlighting some very interesting examples from Carter's research.

Ok, so looking at the java.policy file, we can see that Java is granting us all permissions if it discovers that we’ve used a codebase that points to the local file system, specifically the Java extensions directory.  This is huge, and Heasman continues discussing how we can use this:

You'll remember from last time that by putting a URL in the code attribute allows an arbitrary codebase to specified. Thus if you use a codebase that references the extensions directory (e.g. "C:\Program Files\java\jre1.6.0_03\lib\ext") the applet is granted java.security.AllPermission. The Java documentation doesn't beat around the bush:

Granting AllPermission should be done with extreme care, as it implies all other permissions. Thus, it grants code the ability to run with security disabled. Extreme caution should be taken before granting such a permission to code. This permission should be used only during testing, or in extremely rare cases where an application or applet is completely trusted and adding the necessary permissions to the policy is prohibitively cumbersome.

The only thing left to do is come up with a reliable means of obtaining the path to the "JREx.y._zw\lib\ext" folder. The JRE version can be determined via querying the java.version property from a "bootstrapper" applet. Its probably safe to assume that on Windows platforms the JRE folder resides within the "Program Files\java" folder. As for the drive letter, the browser plugin prevents reading any properties that contain a path (so this rules out using java.home, java.class.path, user.name, user.home and user.dir). You could of course take a guess; "c:" is a pretty good candidate. There is one Windows-specific property, however, that can be read from an unsigned applet and that discloses a full path. The Windows Desktop Properties expose a win.xpstyle.dllName property that can be read as follows:

String dllName = (String)Toolkit.getDefaultToolkit().getDesktopProperty("win.xpstyle.dllName");

On my test box this returns "E:\WINDOWS\Resources\themes\Luna\Luna.msstyles".

So to conclude, the applet tag (which could obviously be generated dynamically) ends up looking like:

<APPLET code="http://2130706433/foo" codebase="file:E:\Program Files\java\jre1.6.0_03\lib\ext"/>

As for a payload, an applet with AllPermission can call Runtime.getRuntime().exec or System.loadLibrary to go straight to native code, fully compromising the browser.

So now the attacker can actually utilize his applet to call the native code, allowing the attacker to compromise the underlying operating system.  This is a much larger attack and is specifically interesting as it leads to a compromise directly.

Thankfully Heasman reported this in a responsible fashion and Sun got a fix turned around to protect us from this type of attack.

Stay tuned for future talks on this subject.  On a side note, I'll be speaking at Black Hat Europe this week with Rob Carter, so if you will be in Amsterdam, come catch up with us at the Movenpick hotel.

-Nate

Topics: Security, Open Source, Software Development

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

0 comments
Log in or register to start the discussion