Java 0-day simple analysis

Preparation
Compile gondvv.javaand generate the file in gondvv.class. create test.htm in the same directory. The content is as follows:

<Applet code = "Gondvv. class" WIDTH = 200 HEIGHT = 100> </APPLET>

A rough look at the java code should bypass Java Sandbox, rather than JVM overflow and other vulnerabilities, so you can directly debug the java code.

SetSecurityManager

First, you need to briefly understand the setSecurityManager () function. SetSecurityManager () is used to set a SystemSecurity. If securityManager has been set, when setSecurityManager is called, checkPermission is called to check whether the permission is correct. You can also call setSecurityManager to replace an existing securityManager. So the method to bypass SandBox is to disable SecurityManager, call the setSecurityManager () function, and pass in the null parameter. For example

First, check the function call chain for the breakpoint under www.2cto.com setSecurityManager () to see where the security manager is modified.

Interrupt in setSecurityManager (), observe the function call chain

You can observe the Code in Gondvv in the call chain and call the Gondvv. disableSecurity () function. And observe that the setSecurityManager () parameter is null, which is an operation to cancel security manager. If the security manager is successfully executed, attackers can bypass the permission check and execute arbitrary commands. The Gondvv code is displayed in the chain. It is untrusted code, but the SecurityManager is still successfully disabled. It is suggested that the permission may be modified.

Code Analysis

The following describes the disableSecurity () function in Gondvv. java.

Create a table dashboard first, and use it to execute setSecurityManager (). However, if it is executed directly, the checkPermission () Check In setSecurityManager () will be triggered, resulting in failure.

Therefore, in Gondvv. java, first modify the context to AllPermission to ensure that the call is performed with the AllPermission permission.

SetSecurityManager () to bypass the check. To prepare the new permissions.

Then, call the key function to complete the permission change within the function.

Create an expression to obtain SunToolkit, which is not available in Java 6 and ClassFinder in Java 7.

You can obtain SunToolkit.

View the implementation of GetClass. It is an expression that calls Class. forName ("sun. awt. SunToolkit") to obtain SunToolkit.

Then, ClassFinder. findClass () is called in Expression. invoke (), as shown in

At this point, we can observe the ClassFinder. findClass () parameter. It is "sun. awt. SunToolkit", and we can get the desired information through the ClassFinder class.

"Acc" is a private member in Statement, which is used to control the access permission of the current Statement context.

GetField () is a public method in sun. awt. SunToolkit, returns an object reference (Field type), and

This method can obtain private members, as shown in figure

The following expression is actually SunToolkit. getField (Statement. class, "acc ").

Back to reference of "acc"

The acc object is successfully obtained. You can directly modify its permissions.

Call the set Method of the Field class and set the passed localStatement context to AllPermission. The localStatement context permission has been modified. You can run this Statement to check the permissions in setSecurityManager, set SecurityManager to null

Execute Statement to execute any command.

Pop-up calc in Exploit

Vulnerability causes

Sun. awt. the SunToolkit itself is part of the security mechanism implementation. According to the SandBox mechanism, untrusted code should not directly obtain the class library, but ClassFinder. findClass () does not take this into consideration. As a result, attackers can obtain SunToolkit, modify their own permissions, and disable SecurityManager.