Posted on by Vulnerability Analysisin
The classic understanding of a Java applet is that it runs in a sandbox in your web browser. This model prevents a Java applet from accessing sensitive resources, such as your file system or registry. So, barring vulnerabilities in the Java Virtual Machine (JVM), Java applets should not have the ability to do anything malicious on your system. That was the case with the JDK 1.0 security model.
Starting with version 1.1, Java included support for signed applets. These applets, which can run in your web browser as the result of viewing a web page, are not limited by any sandbox and can do just about anything that native code can. In other words, a signed Java applet should be treated the same as an EXE file on Windows.
When a web page attempts to run a signed Java applet, the Java Runtime Environment (JRE) will prompt the user before executing the code. When a Java applet without a trusted certificate is started, the JRE will, by default, still allow the user to execute the code. Some versions of JRE may warn the user that the digital signature cannot be verified. For example, the following dialog is presented when the JRE encounters an applet with an untrusted signature, such as a self-signed applet:
If the Java applet is signed with a trusted certificate, the user will still be prompted. However, the option to Always trust content from this publisher is enabled by default. This means that if you run a signed Java applet from one particular vendor, you will trust all Java applets from that vendor by default, regardless of the site that is hosting them. The following dialog is presented when a Java applet with a valid signature is started. Note the default option of trusting all applets signed by that publisher.
Now let's consider the vulnerability remediation steps regarding a signed Java applet. With ActiveX, Microsoft has the ability to deploy a kill bit for a control that is vulnerable. Everybody who is set up for automatic updates from Microsoft will receive the kill bit, which prevents the control from being used in Internet Explorer. But what happens if a vulnerable signed Java applet is discovered? There is no Java analogy to the ActiveX kill bit. An attacker can host a copy of the Java applet on his or her own web site, and that applet will still have a valid digital signature. Keep in mind that just like with ActiveX, a digital signature gives no indication of the safety of running the code. It can only indicate that the code was actually written by the organization that is listed on the signature. And even then, the user has to trust that the Certification Authority (CA) did due diligence in verifying the identity of the code signer.
This lack of remediation options is why I believe that from a security perspective, signed Java is about on par with ActiveX... circa 1996. Internet Explorer started supporting the kill bit and blocking ActiveX controls with invalid signatures in version 4, which was released in 1997.
So how can you protect yourself against malicious or vulnerable signed Java applets? The easiest way is to disable Java, as explained in our Securing Your Web Browserdocument. If you need to use Java, there are other options that can restrict the use of signed Java applets:
The following dialog shows the relevant options. These options are available in the Java Control Panel item for Windows, in the Advanced tab, listed under Security. Other platforms may require different steps.
From the user awareness point of view, if you are ever presented with a dialog that is requesting permission to run a signed Java applet, keep in mind that the code may be malicious. If you do not trust both the Publisher and the From fields in the dialog, you should not run the application.