Archive for July, 2008
Monday, July 21st, 2008
As promised… a quick look at MFSA2008-35:
When FireFox is installed, it registers the following protocol handlers:
Note, Firefox3 no longer registers the Gopher protocol handler, which is a great security decision.
Both of these protocol handlers point to Firefox.exe in the following manner:
- “C:\Program Files\Mozilla Firefox\firefox.exe” -requestPending -osint -url “%1″
When Gopher:// or FirefoxURL:// are called, the arguments are passed to the “%1” portion in the string shown above. For example, gopher://test will result in the following:
- “C:\Program Files\Mozilla Firefox\firefox.exe” -requestPending -osint -url “gopher://test“
Knowing that we have absolute control over the –url argument being passed to Firefox.exe, we can use the “|” character to pass multiple, arbitrary URLs to the –url argument. Firefox has protections against remote web pages from redirecting to file:// and chrome:// content, but in this instance we are passing the URLs via protocol handler. When arguments are passed via protocol handler, it’s essentially as if we are passing the –url argument to firefox.exe via the command line. So, thanks to the protocol handlers the file:// and chrome:// restrictions can be bypassed. This is done in the following manner:
Now that we have the ability to load local content via the protocol handlers registered by Firefox, we must now find a way to plant the attacker controlled content to a known location. There are a couple ways to plant attacker controlled content to a known location, but I’ll keep it simple (and responsible) and use the recently patched Safari “Carpet Bomb” attack as an example. When Safari encountered an unknown content type, it would download the content of the file to the user’s desktop. This gives us a semi known location, as we’ll have to guess the username. We can send a LOT of guesses for username as demonstrated below.
- <html><body><iframe src=”gopher:file:c:/path/filename|file:c:/path/ filename2|file:c:/path/ filename3….>
There are other methods that don’t involve guessing the username, but I won’t go into that (remember, it’s the kinder, gentler BK!).
Firefox3 has implemented security measures to prevent arbitrary file access and limits the XMLHTTP request to the currently loaded directory (and possibly subdirs?), which is a great security decision.
On a side note, IE warns users when active script is about to be run from the local file system. I believe the IE warning message states, “you are about to do something REALLY stupid… do you wish to continue?” … or something like that. This is a great security decision on behalf of IE.
The scenario presented above demonstrates how someone with Safari and FireFox installed could get their files stolen, but Mozilla understood that the behavior of their software could be abused by other software (not just Safari), just as Apple understood that dropping files to a user’s desktop (without consent) could be abused by other software as well (not just IE or Firefox). Both vendors did what was right and adjusted the behavior of their software. Thanks Mozilla and Apple!
These types of issues interest me because it represents the difficulties in securing real life systems, systems that have software from multiple vendors interacting with each other, depending on each other to make the right security decisions. In isolation, these issues may not be of any concern, but together they create a situation where the security measures of one piece of software is bypassed because of the seemingly innocuous/insecure/stupid behavior of another, seemingly unrelated piece of software. From what I understand, Mark Dowd and Alexander Sotirov plan to give some INSANE examples of this at Blackhat… I’m looking forward to the talk!
Thursday, July 17th, 2008
Mozilla issued a patch related to an issue I recently reported to them. The MFSA with details on the issue can be found here. It’s an interesting issue that demonstrates some of the complexities related to interaction between software from different vendors. This particular issue makes use of one of my favorite attack vectors, protocol handlers. The protocol handlers involved in this situation create an opportunity to pass “a command-line URI with the pipe symbols” from a remote webpage to FireFox.exe. For those that are interested, I’ll provide a small writeup on the issue this weekend. For those waiting, I’ll also provide a writeup on the Opera protocol handling issue leading to RCE when the Opera team is ready.
It’s a crazy coincidence that the FireFox and Opera vulnerabilities come almost one year to the date after Nate McFeters and I reported the original firefoxurl and mailto protocol handling vulnerabilities… and I use the term “reported” loosely . Nate and I have changed over the past year… we’re both older and fatter, but it seems that protocol handlers continue to be as vulnerable as ever.
In closing, I want to thank the Mozilla Security Team (Dan Veditz in particular) and the Apple Security Team for working with me on this issue. It would have been easy for them to point fingers at the other organization, but both teams took responsibility for their portion and comitted to changes. Thanks guys! I’ll buy the beers in Vegas!
Friday, July 11th, 2008
I recently came across an issue in Opera that could allow for some bad stuff. Although the issue has been addressed, I’ve been asked by the Opera security team to hold off on details until they can fully investigate other possibly related issues. I’ll respect that request. I do however, want to take a moment to thank the Opera team for their timely response! Change control, resource allocation, and devoting the appropriate amount of testing to patches for sophisticated applications is a tricky business. The Opera team responded quickly with a patch and kept in great contact with me throughout the process.
It’s a crazy world out there and the web browser is the window to the wild wild west. I wish Opera security team the best of luck!