July 16th, 2008
Protocol handlers cause Mozilla Firefox 3 remote command execution vulnerabilities
Update 07/16/2008: Apparently I neglected to mention that this has been patched already. Reading over it again and a heads up from a reader pointed out the error to me. As always, great job by Window Snyder and the Mozilla Security Team for getting this patched quickly.
Billy Rios is at it again. Rios, Rob Carter, and I have made a year and more of our research into exploiting URI/protocol handler vulnerabilities on numerous operating systems and applications, and it appears Rios has ANOTHER one to go with all that previously reported, as well as his most recent vector, which was used against Opera.
Security researcher Billy Rios reported that if Firefox is not already running, passing it a command-line URI with pipe (”|”) symbols will open multiple tabs. This URI splitting could be used to launch chrome: URIs from the command-line, a partial bypass of the fix for MFSA 2005-53 which was intended to block external applications from loading such URIs (that vulnerability remains fixed, however).
This vulnerability could also be used by an attacker to pass URIs to Firefox that would normally be handled by a vector application by appending it to a URI not handled by the vector application. For example, web browsers normally handle file: URIs themselves, or block them from web content altogether, but this flaw enabled attackers to pass them from another browser into Firefox. In Firefox 2 scripts running from file: URIs can read data from a user’s entire disk, a risk if the attacker could first place a malicious file in a guessable location on the local disk. Rios demonstrated that the so-called “Safari Carpet-bombing vulnerability” could be used for this, as well as other techniques that do not rely on that now-fixed Safari vulnerability.
In Firefox 3 scripts running in local files have limited access to other files, almost entirely mitigating the file: attack. However, combined with a vulnerability which allows an attacker to inject script into a chrome document the above issue could be used to run arbitrary code on a victim’s computer. Such a chrome injection vulnerability was discovered in Firefox 3 by Mozilla developers Ben Turner and Dan Veditz who showed that a XUL based error page was not properly sanitizing inputs and could be used in this attack. In the absence of the attack described by Billy Rios this injection attack would not run with any special privilege and would be at best a spoofing vulnerability.
It will be interesting to see if Rios provides proof of concept code, but if you look at the protocol handler registered on the operating system, and how it interacts with Firefox, it may be straightforward. URI and protocol handler abuse continues to be an extremely viable option of attack.
-Nate
Nathan McFeters is a Senior Security Advisor for Ernst & Young's Advanced Security Center in Chicago. The views and opinions expressed in this article are his own and do not represent the views and opinions of Ernst & Young Advanced Security Center or Ernst & Young, LLP. Nathan has performed web application, deep source code, Internet, Intranet, wireless, dial-up, and social engineering engagements for numerous clients in the Fortune 500 during his career at Ernst & Young and has spoken at a number of prestigious conferences, including Black Hat, DEFCON, ToorCon, and Hack in the Box. He can be found at his Pwn* blog and XS-Sniper, a blog with Billy Rios. See his full profile and disclosure of his industry affiliations.
