Java Exploit - Technical Details
posted 9/2/2012 4:02:17 PM
So you've probably seen the Java Exploit topic I've posted about on General Discussions but lets go into some of the technical details about how this exploit works just for fun.
First let's get an understanding of how JRE 7's inner workings in terms of security:
The Java runtime has it's own management system for security but will always defer to the OS's management before using its own. Security in this context refers to the privilege that the Java program is allowed to run at. It can be thought in the same way of security clearances in real life in that some people have clearance to view confidential documents but not secret documents. On a computer, there are typically 2 different clearances: Standard and Administrator. 99% of Java programs on the web do not require an Administrator clearance and will run on a standard clearance which does not require the user to enter credentials.
Now lets say that the user in question does not like User Account Control and has it disabled. This is a common scenario but now that the security management engine in Windows is now disabled (and everything runs with an Administrator clearance), Java's own internal security management will run in an attempt to put a buffer between programs trying to run too many privileges. It usually runs in the same manner but with it's own security levels and will properly ask if you want to run something that requires a little more power.
Now that we have an understanding of the basics behind Java and what the exploit abuses lets get into the fun stuff.
Java has a method called execute which is to go out and find the method that the program or user wants to execute. This requires a little more clearance than usual in order to start programs up so this method and allows certain other functions to run with a better clearance through a process called reflection. One of these privileged methods is known as the getField function which gets arguments required by other methods (that is input required for those methods to do stuff).
This getField also has special bypassing functions and one in specific known as the setAccessible function which does what it says (makes whatever accessible).
So an attacker will abuse this daisy chain to use the 'execute' method to find the getField method which grabs the setAccessible command and runs that on Java's internal Security Management interfaces to overwrite the privileged level to the highest available. Once this is done, the attacker has full access to run any code he wants without anything standing in his way. It does not matter if your plugins are configured to ask if you want to run this Java program as it never works on the highest available clearance. The only blocking method that I know would be the NX bit (known as Data Execution Prevention on Windows) which is hardware level protection that security management cannot overwrite.
And of course once the attacker has the privileges, all he has to do is write a program that does bad stuff to your computer. Since Java exists everywhere, it can be used to attack Windows, Mac, Linux, etc.