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
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 email@example.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:
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
1 2 3 4 5 6 7 8 9 10 11 12
# JNLPAppletLauncher applet-launcher.jar SHA1-Digest-Manifest: 5Bo5/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:
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.
- 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.
- Vendors are the only ones who can submit entries to be
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.
- December 13th, 2011: Email sent to firstname.lastname@example.org informing them of the insecure applet and providing them with a proof of concept.
- December 14th, 2011, 4:09 PM: Reply from Oracle, asking for additional steps to reproduce.
- December 14th, 2011, 5:10 PM: Email sent to Oracle, additional steps provided.
- December 14th, 2011, 8:07 PM: Reply from Oracle, asking for clarification.
- December 14th, 2011, 11:06 PM: Email sent to Oracle, attempting to clarify.
- December 15th, 2011, 4:54 PM: Reply from Oracle, opening case and providing tracking number.
- December 21st, 2011: Reply from Oracle, confirming vulnerability. “We have confirmed the vulnerability in the signed applet from [Vendor]. As the vulnerability is in signed applet, we recommend that you report it to [Vendor] if you had not already done so. Oracle Java SE has a blacklisting feature and [Vendor] may request for their applet to be blacklisted.”
- December 21st, 2011: Email sent to Oracle, asking for clarification on blacklisting policy.
- December 23rd, 2011: Reply from Oracle, reiterating previous email. Suggestion to contact vendor and CC them.
- December 23rd, 2011 7:08 PM: Email sent to vendor with Oracle CC’ed, explaining vulnerability.
- December 23rd, 2011 7:16 PM: Reply from vendor, acknowledging report and forwarding to engineers.
- January 20th, 2012: Email sent to vendor, asking for status update
- January 22nd, 2012: Vendor replies, acknowledges vulnerability, describes additional protections being taken for the future
- January 22nd, 2012: Email sent to vendor, acknowledging their email and thanking them for their diligence to resolve the issue
- February 15th, 2012: Oracle sends email to vendor, explaining blacklisting procedure.
- February 15th, 2012: Vendor replies, forwarding details to engineering team.
- April 9th, 2012: Email sent to vendor, asking for status update
- April 10th, 2012: Reply from vendor. Vulnerability has been addressed in current release. In process of deployment to customers.
- September 1st, 2012: Email sent to vendor, asking for status update
- September 10th, 2012: Reply from vendor. Deployment to customers ongoing.
- September 10th, 2012: Email sent to vendor, asking about blacklisting status.
- September 11th, 2012: Reply from vendor. Will contact me when deployments are closer to completion.
- September 12th, 2012: Reply from Oracle, reiterating the blacklisting procedure.
- September 12th, 2012: Reply from vendor, acknowledging Oracle’s email.
- January 16th, 2013: Email sent to vendor and Oracle, alerting them of plans to publish this blog post on January 23rd
- January 18th, 2013: Reply from oracle, acknowledging email and reiterating blacklisting procedure.