Simple test and brief analysis of remote code execution in Java 0day and Jre

After testing, record the results here:
 
1. Use the poc on the Internet and test it in java6u23, java6b13, and java7u6 respectively. (Why test java6u13? The reason is that the SunToolkit. getField method is public in the lower version of java6. therefore, test to see if the Java 7 vulnerability can be reproduced in the lower version)
 
2. Test whether there are other methods that can replace SunToolkit. getField.
 
Result:
 
1. The original poc does not work in Java 6. It can be used directly in Java 7 and calc is displayed.
 
2. Java 6 of the two versions cannot be broken through. The original poc directly reports an error: access to the awt. SunToolkit package is not allowed in the applet.
 
3. If Java 7 Directly imports this package, the same error is reported. jvm cannot load this package.
 
4. Try other functions. If the test is not successful, you can replace the SunToolkit. getField method.
 
Based on the feedback principle:
 
First, there are two important issues: classFinder and sun. awt. SunToolkit of java 7.
 
1. It limits that only Java 7 can be successful.
 
2. Whether disableSecurityManager can be used in the future is restricted, that is, the sandbox restriction for java code execution is removed. Although this SunToolkit is not irreplaceable (field. setAccessible (true); find this similar code), I did not find a replacement for one afternoon.
 
Because 2 needs to be loaded, so there must be 1 to be loaded with reflection. This is because there is a problem in Java 7 1. SunToolkit that cannot be loaded can be loaded, therefore, a series of subsequent content is triggered. As to whether getField is public or not, it is not tested here, because 1 has directly restricted Java 6 that is public, and it cannot call SunToolkit.
 
The above are the results of today's phased tests. The principle is not guaranteed to be completely correct, but it seems like this according to today's test results. Thank you for @ kxlzx and @ tcpper www.2cto.com.
 
Author: shine
 
@ GaRY
 
There is a question above: Does getField affect public?
 
I just found an example with the question: does the Security Control Mechanism of java reflection seem ineffective?
 
Public class GG {
Public String name = "test ";
}
Public class Test1 {
Public static void main (String [] args) throws ClassNotFoundException, InstantiationException, IllegalAccessException, SecurityException, NoSuchFieldException {
 
Class cls = Class. forName (GG. class. getName ());
 
GG gg = (GG) cls. newInstance ();
Field field = cls. getDeclaredField ("name ");
 
// Field. setAccessible (true );
System. out. println (String) field. get (gg ));
}
}
Whether field. setAccessible (true); or not, you can call the GG type name attribute value because name is public. If it is private, java. lang. IllegalAccessException (security permission exception) is reported ).
 
In java, this is a simple security mechanism. For example, a subclass cannot access the private attributes or methods of the parent class (only accessible through the parent class, such as the public method ).
 
So the setAccessible (true) of the reflection mechanism does have a big problem here!
 
@ F4tb0y configure the Java environment, save the saved file as a. Java file, and compile it as a. classfile to create a. html
 
. Html content
 
<Applet code = "class name. class" width = "0" height = "0"> </applet>
Put the two files in the same folder and run the. html file!
 
Shine (shield) |
 
@ Shine the phrase "can call the GG type name attribute value" should be changed --- "" can call the GG class name attribute value"