Indistinguishable from Jesse

Adam Sacarny, author of the Mozilla shell: vulnerability timeline, discusses what Mozilla can do to work around future holes in programs that register themselves as protocol handlers.

I discovered arbitrary code execution holes in Firefox, Internet Explorer, and Opera that involve human reaction time. One version of the attack works like this:

The page contains a captcha displaying the word "only" and asks you to type the word to verify that you are a human. As soon as you type 'n', the site attempts to install software, resulting in a security dialog. When you type 'y' at the end of the word, you trigger the 'Yes' button in the dialog. I made a demo of this attack for Firefox and Mozilla.

Another form of the attack involves convincing the user to double-click a certain spot on the screen. This spot happens to be the location where the 'Yes' button will appear. The first click triggers the dialog; the second click lands on the 'Yes' button. I made a demo of this attack for Firefox and Mozilla.

These types of attack work on any security dialog that can be triggered by untrusted content. The attack is most useful in a dialog where one of the buttons means "Yes, let this untrusted content run arbitrary code". Firefox has such a dialog in the form of the extension installation (XPI) dialog. Similarly, Internet Explorer has the ActiveX installation dialog and Opera has an "Open" button for downloaded executables. Programs other than browsers might also be vulnerable.

Firefox's solution, from bug 162020, is to delay enabling the "Yes"/"Install" buttons until three seconds after the dialog appears. I believe that this is the only possible fix other than completely denying untrusted content the ability to pose the dialog. Unfortunately, this fix is frustrating for users who install extensions often.

Some users have been intentionally lowering the delay to 0 seconds, which frustrates me. These users think the delay was added merely to force everyone to read the dialog. It surprises me that these users were not able to figure out the security hole given the fix. Ironically, advanced users are the most susceptible to these attacks, because they type and double-click faster than they react to unexpected stimuli.

It might be possible to lower the delay to less than three seconds, making it less annoying, without jeopardizing security. Designing experiments to determine the minimum "safe" delay would be tricky. You would want to do everything an attacker could do to increase participants' reaction time: give them a complicated task, make new rectangles appear every second to make the dialog less unexpected, etc.

It might make sense to make the dialog appear only after the user clicks a statusbar indicator that means "This web site wants to install software". This would get rid of the problem of choosing a delay, and it wouldn't require users who want to install extensions to wait.

Slashdot reports a "new" spoofing hole in many browsers, including older versions of Mozilla, discovered by Mark Laurence. The hole is that site A can load its own content into a frame on site B, and the content will appear to be from site B because the frameset is still from site B. This attack only works if site B is a framed site, so some banks are not affected.

A comment I posted on Slashdot:

Lorenzo Colitti and I found the same hole several weeks ago, independently of Mark Laurence. I reported it to mozilla.org on June 11 and to Microsoft and Opera on June 16. I got different results from each browser maker:

Mozilla (bugzilla.mozilla.org 246448)

Fixed on June 14. Firefox 0.9 released with the fix June 14. Mozilla 1.7 released with the fix June 17.

Opera (bugs.opera.com 145283)

No response.

Microsoft

On June 21, I received an e-mail containing the following: "... is by design. To prevent this behavior, set the 'Navigate sub-frames across different domains' zone option to Prompt or disable in the Internet zone. We are trying to get this fixed in Longhorn ... on getting this blocking on by default in XP SP2 but blocking these types of navigations is an app compatibility issue on many sites." I usually don't get any response from Microsoft when I report security holes to them; I think I only got a response this time because I used my employer's premier support contract with Microsoft.

Another cross-browser security hole I found (bugzilla.mozilla.org 162020) got similar responses from each browser maker: fixed in Mozilla 1.7 and Firefox 0.9; no response from Opera; confusing statement from Microsoft mentioning XP SP2. 162020 is an arbitrary code execution hole.

To be fair to Microsoft, the fix for the frame-spoofing hole did break a few sites. According to a bug filed today, the Charles Schwab brokerage site is one of the broken sites.

I had to install Enigmail and gpg in order to send a vulnerability report to CERT.

I am not happy with gpg's UI. I had to read this page to figure out which command-line options I had to use. GPG gives a vague yet serious-sounding warning if you use an empty "passphrase" when creating your key. (As far as I can tell, a strong passphrase protects you against someone who can read the file containing your private key, but other than that it doesn't increase security.) It asked me to move the mouse around and bang on the keyboard while it generated my keys, but it generated the keys in less than a second, making me worry that it didn't use any good sources of entropy when it created my key.

I was able to figure out how to use Enigmail without much trouble. I encountered lots of warning and error messages, but I think they were all necessary. (I didn't like the text "This message will appear 1 more time" at the bottom of most of the warnings, though. I don't want Enigmail to keep me from making a mistake just because I almost made the mistake 2 times in the past!) Enigmail's options were split between the Options window and the Account Settings window, but that's a problem with Thunderbird in general.

Neither CERT nor Enigmail warned me that the subject of my e-mail would be sent unencrypted.

Hixie helped me report a security hole to Opera. Then Hixie and his friends at the W3C Technical Plenary tried to help me report it to Microsoft, offering these suggestions:

• "There's probably a form on microsoft.com/ie."
• "You report it to cnet."
• "You break into Microsoft's systems using the exploit, and insert the bug into their bug system. Since you can only do that with security bugs, that filters out the non-security ones."

I think I reported the bug to Microsoft successfully. The language on Microsoft's form ("enchancement suggestion" and "wish" rather than "bug report") was discouraging, but I did get to check a box labeled "Security".

Three hours before Firefox 0.8 was released, I found a security hole in Mozillazine: you could see the titles of unpublished articles (e.g. http://mozillazine.org/talkback.html?article=4283) in the titlebar. Using this hole, I accidentally discovered the name change before the release. The hole has been fixed.

jesus_X informs me that long ago, MozillaZine let you see the full text of unpublished articles. I guess the original hole was partially fixed, leaving only the title of the article visible.

This simple hole allows any site to change your Google preferences behind your back. Someone could change your Google interface language to Pig Latin. (Why Pig Latin rather than, say, Russian? It's more fun, and the "Google.com in English" link isn't as obvious when the surrounding text looks like English.) Someone could make your searches only turn up English results. Worst of all, someone could stop you from using Google to search for porn by turning on SafeSearch.

Slashdot's solution to this type of hole is "formkeys". I don't know how other sites solve it. But one incorrect solution is to check referrers. (Update May 5, 2005: I'm no longer sure checking referrers is incorrect.)

Webmasterworld's "hitchhiker" and I found a security hole in Google today. He searched for something like "this can't be true" and his browser reported a JavaScript syntax error. I pointed out that with a carefully constructed query string, you can get Google to spit out something syntactically valid that does whatever you want. For example:

http://www.google.com/search?q='+alert(document.cookie)+'
causes Google to generate the following onClick attribute: onClick="c('http://images.google.com/images?q='+alert(document.cookie)+'
&hl=en&lr=&ie=UTF-8&c2coff=1&safe=off','wi',event);"

If you follow the link and click a tab (web, images, groups, directory, news), you'll see your Google cookie in a dialog.

Hitchhiker responded:

I just can't believe G made that kinda mistake.

ESCAPE ESCAPE!

Escaping is not always the best solution. When I found a similar hole in some JavaScript code in Mozilla, ducarroz's solution was to use an alternative window.setTimeout syntax. The normal version of setTimeout takes a string to be parsed and executed; the alternative version takes a function and parameters. Instead of escaping the untrusted input, we avoided parsing a string containing the untrusted input.