07.02
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:
- Applet downloads executable (provided as a parameter to the applet named
source) - Applet verifies signature for executable (the signature is also provided as a parameter)
- 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.comincluding 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.