A look at the recent Firefox 3 vulnerability

A look at the recent Firefox 3 vulnerability

Summary: True to form, Billy Rios promised a more in depth look at the MSFA2008-35 vulnerability which is another protocol handler flaw in Firefox 3.  As previously reported here, this was another protocol handler flaw that led to arbitrary remote command execution, and is especially dangerous since it can be deployed widely through the use of a cross-site scripting attack vector.


Billy RiosTrue to form, Billy Rios promised a more in depth look at the MSFA2008-35 vulnerability which is another protocol handler flaw in Firefox 3.  As previously reported here, this was another protocol handler flaw that led to arbitrary remote command execution, and is especially dangerous since it can be deployed widely through the use of a cross-site scripting attack vector.

Read the details below.

From Rios's XS-Sniper blog:

As promised… a quick look at MFSA2008-35:

When FireFox is installed, it registers the following protocol handlers:

  • Gopher://
  • FirefoxURL://

gopher is cool!

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:

  • gopher:test|file:c:/path/filename
  • gopher:test|chrome://browser/content/browser.xul

Note – It is also possible to pass “javascript://” URIs to Firefox.exe, but javascript URIs passed via the command line will be loaded in the context of about:blank.  This is a great security decision on behalf of Mozilla and saved them from having a standalone sploit.

The last point there is a key security concern, but I think you can already see that this is going to be a problem.  Back to Rios:

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!).

Does anyone still think that allowing files to be dumped to predictable locations is NOT a vulnerability?  Who cares how it's kicked off, the fault is that you're allowing content to be place on a system in a predictable location, WITHOUT user interaction, and you're just hoping no one else has done that piece in a secure fashion and is therefore OK with files being executed.  There are actually other nastier ways of putting content onto someone's file system through applications, which Rios and I will discuss in a future advisory once people have had time to fix the issues.  Back to Rios:

So, if a user is browsing the web with Safari and has Firefox installed, I could plant a HTML file with javascript (XMLHTTP) onto the user’s desktop.  Once the content is planted, I can launch the gopher:// protocol handler (gopher is launched by Safari without user consent) and point Firefox.exe to the local content.  When Firefox loads the local content, the XMLHTTP request has access to the entire user file system (as the script was loaded from the local file system).

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!

A great walk through of a technical issue, but I think everyone can see, while this one was complex in nature, it's a straightforward concept to exploit, and could be potentially quite devastating.


Topics: Operating Systems, Apple, Browser, Security

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • LOL

    Always makes me laugh when a Firefox article is written critical of it, no one adds an opinion.

    If this were about IE, the thread would be huge.
    • Maybe we're all busy.

      I think the DNS vulnerability http://blogs.zdnet.com/security/?p=1460 has grabbed the spotlight from this. As bad as this vulnerability is, this DNS vulnerability is much worst.
      This vulnerability in Firefox, if exploited correctly, will be a big thing. However with this vulnerably you need to know several variables before it can be properly exploited on any system, but since many people leave their system default this is major flaw that one may use to take advantage of any system. To temporarily mitigate this issue is one can change one handles certain protocols so default values are not used.
      It appears that this bug is easy to fix so I wish that Mozilla will fix it soon.
    • If it were IE it wouldn't be ALREADY FIXED, lol... nt

  • quit making such a big deal, read more

    Why do people write about security vulnerabilities that have happened in the past? They're fixed in the most recent version. What you writers have nothing better to do then harass Mozilla about something they didn't know about until they found out? No offense, but to me it's no big deal because it's something that has been patched.

    Think before you write something.

    goodman john.
    • Right

      Apparently they don't read very carefully. In case anyone is still confused, I'll say it again, real slowly: this...has...been...fixed.
  • http://news.cnet.com/Torvalds-attacks-IT-industry-security-circus/2100-1007


    'nuff said.

    Real developers and architects are rather tired of the self-overestimated networking and hacker crowd jumping on every bandwagon known to man and making things so security-centric that we can never get around to actually making anything new without someone damning potential into the ground on security issues before the technology itself is able to be examined.

    It's funny that you all constantly impune the integrity of software over every niggling bit of minutae you can dredge up, but never actually produce anything yourself.

    Security issues should be a footnote in a bug tracker, not 10k duplicate blog entries by do nothing blowhards. So, at the end of the day, how does it feel to be a professional fear monger?