Java exploits represent a common attack vector used by the bad guys to infiltrate vulnerable computers via the web browser. We wrote about the rise of Java exploits as early as 2010, and we haven’t seen that trend decline. In fact, in the first quarter of 2013 alone, we’ve seen three Java remote code execution vulnerabilities being exploited in the wild: CVE-2013-0422, CVE-2013-0431, and CVE-2013-1493. In response, Oracle recently introduced a new security feature regarding the way unsigned Java applets and web start applications are run in the release of Java 7 update 11. The text in Oracle’s release notes reads:
Synopsis: Default Security Level Setting Changed to High.
The default security level for Java applets and web start applications has been increased from “Medium” to “High”. This affects the conditions under which unsigned (sandboxed) Java web applications can run. Previously, as long as you had the latest secure Java release installed applets and web start applications would continue to run as always. With the “High” setting the user is always warned before any unsigned application is run to prevent silent exploitation.
Today, the vast majority of applets exploiting security vulnerabilities are not signed; this basically means that every time a user opens a webpage that tries to load an unsigned applet (which is a classic exploitation scenario), there is a risk that the computer will get infected. This scenario is known as a drive-by attack.
This new security enhancement eliminates the risk of silent exploitation using drive-by attacks via unsigned applets, which were possible before Java 7 update 11. This leaves attackers with no choice but to use social engineering techniques to convince users to click the Run button on the security warning dialog (displayed below). While still possible, it’s no longer as easy for them to infect your computer.
With the new security enhancement, the following dialog box appears when you visit a webpage hosting an unsigned Java applet:
If you don’t expect to see an applet on the page, we strongly advise you to click Cancel. In fact, we advise you to click Cancel by default for untrusted pages (don’t check the “Do not show this again for this app” box), check the loaded webpage, and choose Run only if you truly believe that the applet is risk free, that is:
- It is the webpage you expected to see.
- The URL in the dialog box matches with the URL of the page you’re viewing (in case the dialog originated from another browser tab).
- The applet was not hidden and you see the text:
in the location where the applet’s canvas should have been painted.
Keep in mind that in case the webpage tries to load multiple applets, there’s going to be one dialog box for every applet. We recommend you assess each one individually. You can then hit the refresh button on your browser when you’re done, and when the security warning dialog reappears, you can click OK if you think the applet is safe.
What about self-signed Java applets? These applets, although signed, do not use a certificate from a recognized certificate authority, hence they still require your approval to run. This is also a known scenario used by attackers (we detect variants used in these kinds of attacks as TrojanDownloader:Java/Toniper). In such a situation, the following dialog box will appear:
As you can see, in the self-signed scenario the warning is presented in an even more clear fashion, as opposed to the previous unsigned warning where it didn’t clearly state the risk. Signed applets run as trusted code, without any restrictions, and can run arbitrary code on your computer. This means that a signed applet doesn’t need to exploit a vulnerability to potentially take control of your computer. It just needs to be allowed to execute.
Again, in this scenario, we recommend that you click Cancel for untrusted webpages. However, note that clicking Cancel on this dialog doesn’t mean you don’t allow it to execute, only that you’re not allowing this applet to run with full access. After clicking Cancel another dialog will pop up, like the one presented in the first picture, which asks you if you will allow it to execute. It is because of this that it is imperative that whenever you are redirected to such a page, you do not allow the applet to run initially. Please see steps 1 to 3 described above on how to properly assess the situation and decide whether to allow the applet to run or not.
As it stands today, thanks to Java 7 update 11, only Java applets signed with a trusted certificate are allowed to run without asking the user’s permission, if not requesting full permissions. It is uncommon to see malicious trusted signed Java applets. To protect yourself in all scenarios we strongly advise you to use an up-to-date antivirus solution and software (e.g. Java Runtime), and follow best practices when browsing the Internet, especially on opening links coming from untrusted sources.
Also, starting with Java 7 update 21, planned for today, April 16, 2013, the look and feel of the above dialog boxes will change slightly to further highlight the potential danger of running unsigned code. Please read more here and see how the new dialog boxes will look here.
Kudos to our friends in Oracle for taking these steps to improve Java security.
Marian Radu
MMPC Munich
