Summary

Over a year ago I identified a signed Java applet which could be used to download and execute arbitrary applications onto a user’s machine. I reported this applet to Oracle and to the vendor. Although the vendor has worked to provide an updated, secure version of the applet to its clients, Oracle has taken no action to disable the insecure version of the applet.

Given the current discussions on the state of Java security, I felt it appropriate to highlight a feature of Java which isn’t used very much and which many people don’t know about: the JAR blacklist. This feature could be used more effectively to address situations where signed Java applets can be abused.

How does the JAR blacklist work?

Oracle describes the blacklist as follows:

A blacklist is a list of signed jars that contain serious security vulnerabilities that can be exploited by untrusted applets or applications. A system-wide blacklist will be distributed with each JRE release. Java Plugin and Web Start will consult this blacklist and refuse to load any class or resource contained in a jar file that’s on the blacklist.

There are two blacklists that are used: a system-wide blacklist that is distributed with Java ( deployment.system.security.blacklist ) and a user-determined blacklist ( deployment.user.security.blacklist ). On my laptop they were in C:\Program Files\Java\jre7\lib\security\blacklist and C:\Users\USERNAME\AppData\LocalLow\Sun\Java\Deployment\security\blacklist ,

respectively.

The blacklists are simply hashes of the signed JARs: when a JAR is downloaded, the JRE refuses to run it if its signature matches the blacklist.

As Oracle’s description of the JAR blacklist mentions, the system-wide blacklist is distributed with each release of the JRE. That means in order to blacklist a new applet, a new version of the JRE needs to be released.

Oracle does not appear to proactively add entries to the blacklist. Instead, vendors can reach out to Oracle by emailing secalert_us@oracle.com to ask that their applet be blacklisted. Below is an email that was sent to me and the vendor by an employee of Oracle regarding their blacklisting policy:

Java SE includes a mechanism for blacklisting jars. See “Blacklist Jar Feature” at: http://www.oracle.com/technetwork/java/javase/6u14-137039.html We can evaluate including blacklist entries for your signed applet and will need the following information: * Company name and address

* Company web page address (URL)

* Contact for company 1. Are you the publisher of the vulnerable jars?

2. How many jars are affected (this should include all versions that have been released)?

3. What is the link to the advisory for the vulnerability?

What applets are currently blacklisted?

I extracted the latest blacklist from my installation of Java (found in C:\Program Files\Java\jre7\lib\security\blacklist ):

1 2 3 4 5 6 7 8 9 10 11 12 # JNLPAppletLauncher applet-launcher.jar SHA1 - Digest - Manifest : 5 Bo5 / eg892hQ9mgbUW56iDmsp1k = # 7066583 SHA1 - Digest - Manifest : x17xGEFzBRXY2pLtXiIbp8J7U9M = SHA1 - Digest - Manifest : ya6YNTzMCFYUO4lwhmz9OWhhIz8 = SHA1 - Digest - Manifest : YwuPyF / KMcxcQhgxilzNybFM2 + 8 = # 7066809 SHA1 - Digest - Manifest : dBKbNW1PZSjJ0lGcCeewcCrYx5g = SHA1 - Digest - Manifest : lTYCkD1wm5uDcp2G2PNPcADG / ds = SHA1 - Digest - Manifest : GKwQJtblDEuSVf3LdC1ojpUJRGg =

7066583 corresponds to a vulnerability in the Cisco AnyConnect Mobility Client, while 7066809 corresponds to a vulnerability in the Microsoft UAG Client applet. That’s a total of 7 JARs over 3 distinct products.

To blacklist the applet that I discovered, you can add the following line to your user blacklist file:

SHA1 - Digest - Manifest : juvzxh6HWxwJuK / Vz267YFzTgqw =

Note that there may be other, older versions of the applet that I am not aware of.

How does the blacklist feature compare to other systems?

The system-wide blacklist is tied to a JRE release

This is in contrast to the blacklists used by Google Chrome and Firefox to block malicious extensions: such lists can be updated dynamically and are not tied to a software release.

release This is in contrast to the blacklists used by Google Chrome and Firefox to block malicious extensions: such lists can be updated dynamically and are not tied to a software release. The blacklist has a total of 7 entries

To compare, Google Chrome’s blacklist has 450 extensions listed on it, while Firefox has blocked numerous add-ons over the years.

To compare, Google Chrome’s blacklist has 450 extensions listed on it, while Firefox has blocked numerous add-ons over the years. Vendors are the only ones who can submit entries to be blacklisted

I’m not aware of other blacklists where this is a requirement. Most other systems will take into account user reports and perform their own evaluations.

Vulnerability Details / Disclosure Timeline

The vulnerable signed JAR itself is not very interesting: it’s designed to download and run an executable specified by a properties file, which is in turn hosted on a server. At no point is there any validation of the properties file or executable; as such, it’s trivial to take the JAR and point it at an attacker-controlled properties file, which in turn points to an attacker-controlled executable. It’s a textbook example of a bad signed JAR and is fairly trivial to exploit.

The vendor has since released a version of their JAR which requires a valid signature for any executable that is downloaded. However, because the old applet is still available on the Internet and has not been blacklisted, it is potentially valuable for attackers. For that reason I have chosen not to release the vendor’s name.

Below is a timeline of all communications between me, the vendor, and Oracle. Unless otherwise stated, emails sent to the vendor were also CC’ed to Oracle.