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.
[Source: zdnet]
Post a Comment