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
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
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
firstname.lastname@example.org 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
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
# JNLPAppletLauncher applet-launcher.jar
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
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
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
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 email@example.com
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
- December 14th, 2011, 8:07 PM: Reply from Oracle, asking for clarification.
- December 14th, 2011, 11:06 PM: Email sent to Oracle, attempting
- 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
- February 15th, 2012: Vendor replies, forwarding details to
- 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
- September 11th, 2012: Reply from vendor. Will contact me when
deployments are closer to completion.
- September 12th, 2012: Reply from Oracle, reiterating the
- 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.