1. purpose
Now security researchers and major manufacturers have paid more and more attention to Java exploit. Because a good java vulnerability (not all) can not worry about the operating system platform, DEP and ASLR, and its stability is far better than some IE and flash vulnerabilities, it is also increasingly favored by some developers of exploit kit. The figure below shows the exploit statistics detected in the security announcement of Microsoft in the first half of 2011. You can see that Java has been in the leading position.
Based on the more and more important position of Java exploit in the field of vulnerability research, I write this article in the attitude of casting bricks and attracting jade, hoping to help you understand java exploit.
2. Java in web page
At present, there are mainly two ways to start java code in web pages: applet and Java Web launch. Among them, Java Web launch is a new addition after Java 1.5, while applet has existed for a long time. I remember when the school taught Java, the last big assignment was to write an applet with complex functions. But now applet is not popular. Add the following code to HTML to embed applet:
Add the following code to HTML to embed the applet:
Code:
Or if it is packaged into jar:
Code:
In contrast to applet, Java Web launch is used to start Java application from the web. You need to follow the Java Network launch protocol (JNLP).
3. Security and sandbox
See here, you may think, since we can freely call the Java applet in HTML, and the function of Java language is very powerful, then writing a Java applet containing malicious code to the Internet is not equivalent to hanging a horse. For example, you might want to write the following code:
Code:
public class HelloWorldApplet extends Applet { public void init() { try { Runtime.getRuntime().exec("calc.exe"); } catch (IOException e) { e.printStackTrace(); } } public void paint(Graphics g ) { g.drawString("Hello World!",5,35); }}
Then add the following code to your web page to call the applet:
Code:
Then hang the web page on a certain server, and start to wait for others to make a cup of tea. I hope that all the students who visit this page through the browser will be shocked by the pop-up calculator, but their life is not satisfactory. In all likelihood, let's see the actual effect
Er, there is an error. We get an accesscontrolexception, indicating that we do not have permission. In fact, Java designers have long considered security issues and proposed the concept of sandbox. In short, the meaning of sandbox is: Java virtual machine is performing all the operations related to system resources (reading and writing files, running commands, network communication...) If you do not have permission, an exception will be thrown. The whole sandbox mechanism is very complex and cannot be explained in a short space. Here are just some key points:
In fact, Java designers have long considered security issues and proposed the concept of sandbox. In short, the meaning of sandbox is: Java virtual machine is performing all the operations related to system resources (reading and writing files, running commands, network communication...) If you do not have permission, an exception will be thrown. The whole sandbox mechanism is very complex and cannot be explained in a short space. Here are just some key points:
1. The code running in Java virtual machine can be divided into trusted code and untrusted code. By default, the code in Java's own libraries is trusted, while the code from other places (such as the network) is not trusted. By default, trusted code can operate on any system resource without restriction, and the permissions of untrusted code are very low. For example, in our previous example, helloworldaplet.class is untrusted because its code comes from the network. When trying to create a process (processbuilder. Start() function), the Java virtual machine checks that the current code is not trusted and throws a permission exception. We can define some means to make our code trusted (such as adding policy, code signature, etc.). 2. When checking the permissions of Java virtual machine, the code on the whole call stack will be checked instead of the current function (there will be some exceptions, such as doprivileged and accesscontrolcontext, which can be ignored temporarily). As long as there is any call from untrusted code on the whole call stack, it is determined that there is no permission. In the above example, when the permission is finally checked, the call stack is as follows:
2. When checking the permissions of Java virtual machine, the code on the whole call stack will be checked instead of the current function (there will be some exceptions, such as doprivileged and accesscontrolcontext, which can be ignored temporarily). As long as there is any call from untrusted code on the whole call stack, it is determined that there is no permission.
In the above example, when the permission is finally checked, the call stack is as follows:
Code:
The HelloWorld applet code for ourselves is untrusted, so the entire check fails and the exception is thrown. 3. Whether the permission check code is interspersed in the relevant Java API or in our example above, runtime.exec calls processbuilder.start, and the code is as follows:
3. Whether the permission check code is interspersed in the relevant Java API or in our example above, runtime.exec calls processbuilder.start, and the code is as follows:
Code:
for (String arg : cmdarray) if (arg == null) throw new NullPointerException(); // Throws IndexOutOfBoundsException if command is empty String prog = cmdarray[0];
SecurityManager security = System.getSecurityManager(); if (security != null) security.checkExec(prog);
String dir = directory == null ? null : directory.toString();
try { return ProcessImpl.start(cmdarray, environment, dir, redirects, redirectErrorStream); } catch (IOException e) { // It's much easier for us to create a high-quality error // message than the low-level C code which found the problem. throw new IOException( "Cannot run program "" + prog + """ + (dir == null ? "" : " (in directory "" + dir + "")") + ": " + e.getMessage(), e); } }}
Note that the securitymanager.checkexec in it is the permission check code. Securitymanager is the core of Java security mechanism. A running Java virtual machine may or may not have a securitymanager, but once the securitymanager is set, it cannot be changed. Without securitymanager, many permission checks will not occur. If you run a java program locally, there is no securitymanager by default, but if you start an applet through a browser, the corresponding browser must set a securitymanager.
4. Several types of Java exploit
Through the previous introduction, we know that due to the protection of sandbox mechanism, under normal circumstances, we can't do bad things with Java programs, so what Java exploit needs to do is obvious: break through the protection mechanism of Java sandbox. Imagine that we are now locked in a closed house and want to escape, then we may have two ideas: 1. Smash the wall directly. 2. Look for the doors and windows in the house or the tunnel. Among the existing Java vulnerabilities, the first method corresponds to those vulnerabilities that exploit Java virtual machine implementation (mainly including runtime) and plug-ins, such as cve-2009-3867, cve-2009-3869, cve-2010-3552, cve-2010-0886, etc. The main idea of this kind of vulnerability is: Although Java program runs in virtual machine, the implementation of the whole virtual machine (including Runtime Library) needs platform related local code to support (on windows, there are local codes such as awt.dll, java.dll, etc.). If there are loopholes in these codes, and they can be triggered by java code, we can use these loopholes to run shellcode. At this time, the sandbox mechanism is powerless (because sandbox is for Java code). Let's take an example, cve-2009-3867. This is a stack overflow vulnerability. It exists in getsoundbank function of Java midisystem class. We can trigger this vulnerability by passing an extra long URL. See the code:
Imagine that we are now locked in a closed house and want to escape, then we may have two ideas: 1. Smash the wall directly. 2. Look for the doors and windows in the house or the tunnel.
Among the existing Java vulnerabilities, the first method corresponds to those vulnerabilities that exploit Java virtual machine implementation (mainly including runtime) and plug-ins, such as cve-2009-3867, cve-2009-3869, cve-2010-3552, cve-2010-0886, etc. The main idea of this kind of vulnerability is: Although Java program runs in virtual machine, the implementation of the whole virtual machine (including Runtime Library) needs platform related local code to support (on windows, there are local codes such as awt.dll, java.dll, etc.).
If there are loopholes in these codes, and they can be triggered by java code, we can use these loopholes to run shellcode. At this time, the sandbox mechanism is powerless (because sandbox is for Java code).
Let's take an example, cve-2009-3867. This is a stack overflow vulnerability. It exists in getsoundbank function of Java midisystem class. We can trigger this vulnerability by passing an extra long URL. See the code:
Code:
A strcpy operation in the Java runtime raises this vulnerability:
Very typical stack overflow, you can debug it yourself. It is worth noting that if you access exploit and debug through IE browsing, ie will terminate the Java virtual machine after a period of time when it does not get a response. You can prevent Java from being shut down by breaking on and off the terminate process of IE. Look at cve-2010-3552 again. It's also stack overflow, but the target of this attack is java browser plug-in:
Look at cve-2010-3552 again. It's also stack overflow, but the target of this attack is java browser plug-in:
Is the popular browser plug-in overflow. When the docbase parameter is too long, the vulnerability is triggered. The second way to break through Java sandbox is to "bypass": the idea of using sandbox to ensure security is very good, but people are not sages, and there is no fault. When the code is really implemented, the big bulls who develop java still occasionally make some small mistakes, leading to the sandbox mechanism can be bypassed in some cases. Typical are cve-2010-0840 and cve-2011-3554 of the previous days. I personally feel that this kind of vulnerability is more harmful than the first type of "violent attack on Java virtual machine". Because attackers don't need to think hard about how to make their exploit stable, don't need to think about annoying dep and ASLR, just write a piece of bad java code. Now let's see cve-2010-0840: Daniel's blog has been very detailed:
The idea of using sandbox to ensure security is very good, but people are not sages, who can do nothing wrong. When it comes to code implementation, the big bulls who develop java will occasionally make some small mistakes, resulting in the sandbox mechanism can be bypassed in some cases.
Typical are cve-2010-0840 and cve-2011-3554 of the previous days.
I personally feel that this kind of vulnerability is more harmful than the first type of "violent attack on Java virtual machine". Because attackers don't need to think hard about how to make their exploit stable, don't need to think about annoying dep and ASLR, just write a piece of bad java code.
Now let's see cve-2010-0840: Daniel's blog has been very detailed:
http://slightlyrandombrokenthoughts....-cve-2010.html
Let me summarize. The core idea of this vulnerability is as follows: as mentioned earlier, when Java sandbox permission checks, it will check the entire stack code. As long as there is any untrusted code, the check will fail. Cve-2010-0840 turns off the security of sandbox by constructing an expression that will execute setsecurity Manager (null). Calling setsecuritymanager triggers a permission check, so there is no permission to execute this expression directly in our own code. But by adding this expression to a JList container and letting the applet's UI thread execute this expression, you can realize that the entire call stack is Java's own trusted library code when checking permissions. The Java sandbox was successfully bypassed.
As mentioned earlier, when Java sandbox permission checks, it will check the code on the whole stack. As long as there is any untrusted code, the check fails. Cve-2010-0840 turns off the security of sandbox by constructing an expression that will execute setsecurity Manager (null). Calling setsecuritymanager triggers a permission check, so there is no permission to execute this expression directly in our own code. But by adding this expression to a JList container and letting the applet's UI thread execute this expression, you can realize that the entire call stack is Java's own trusted library code when checking permissions. The Java sandbox was successfully bypassed.
5. summary
Finally, I hope this article can help you understand some java security related knowledge.