Java certificate checks botched

The signature looks legitimate but there's a sting in the tail.
Source: Eric Romang While the focus regarding the recent Java 0day exploits has been on blocking unsigned applets – ones with no verifiable digital signature – security researcher Eric Romang reports on a new problem, signed Java JARs that carry malware. The malware in question was found on dict.tu-chemnitz.de, a German online dictionary which had apparently been infected by the g01pack exploit kit.

The code in the web page named the JAR file as "ClearWeb Security Update" and said it had been signed by "CLEARESULT CONSULTING INC.". The company is a real company and the signature gives the jar file the appearance of it being secure and therefore the security measure to stop unsigned applets running did nothing.

Instead, a dialog was displayed asking whether the user wanted to run the application with no hint of any problem; even opening up the "More details" and "Certificate Details" gave no indication of issues. Only there were two problems. Firstly, the applet had been signed with a presumed stolen private key and, as Avast's Jindrich Kubec found, that key had been revoked on 7 Dec 2012. If the user pressed run, the application would have begun installing malware onto the system.

Behind this problem is the simple issue that by default, although Java runtimes verify certificates, they do not check them for revocation. This is made worse by the fact that they also, as a default setting, grant both signed applications and self-signed applications elevated privileges. Although attackers have used stolen certificates before, the current settings on Java runtimes mean that just because a package is signed doesn't mean it can be trusted because the certificate is not being tested for revocation.

Users should at least consider going to the Java control panel to activate the certificate revocation test and reduce the privileges of signed applications. Given the sorry state of the Java web plugin's security handling at the moment though, it would be simpler to enable the click-to-play functionality for plugins or just disable the Java plugin in the browser to stop exposure to all Java code on the web.

(djwm)