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