Rational Action

It looks like a few people liked my Mozilla Bug Fix timeline. And a few didn’t. Unfortunately I ended up posting the thing at something like 3AM, and I didn’t get to write out everything I wanted to say. Now I have some incentive to finish.

The Mozilla developers did a great job handling this extremely critical security hole. After getting word of an exploitable hole, they pushed out a fix in less than 36 hours. Applause. The system worked.

…but not perfectly. The critical bug got fixed in a jiffy, but it was actually the result of known weaknesses in the way Mozilla handles external protocol handlers. These weaknesses came up many times on Bugzilla, starting around 2 years ago. The developers quelled some concerns by implementing an insecure protocol blacklist, but this solution did not fix everything. What I propose here would not have plugged this security hole entirely, but it would have mitigated it to a great deal. I can’t see how the Mozilla team could have prevented this problem entirely, but had they handled several known bugs, it could have been a minor issue.

Those who feel Mozilla completely botched this bug often point to Bugzilla bug 167475 and bug 173010. Although the latter bug would have fixed the problem completely, it also would have made Mozilla far less usable. The former bug would have mitigated but not fixed the problem. Let’s take a deeper look into the issue:

An Internet Explorer user on Windows has many protocols available to him within his web browser: the protocols IE supports itself, certain add-on protocols supported by Windows, and more add-on protocols implemented by other applications. See http, shell, and ed2k as respective examples. On Windows, Mozilla recognizes these protocol handlers in addition to its own. And, as these bugs point out, Mozilla will launch the associated application whether the link to the handler is in an A tag, where it would make sense, or in an IFRAME, where it really wouldn’t. Since the shell: protocol is insecure, an unpatched Mozilla user could theoretically infect himself by simply going to a webpage with a malicious IFRAME.

The solution in bug 167475 initially is to block external protocol handlers outside of A tags. It’s not a real fix, though: one commenter notes that “It’s not hard for a malicious site to get a visitor to click a link”. Fixing the bug in that way would have resulted in a false sense of security, as websites could still trick users into clicking on malicious anchors. Still, Mozilla should have blocked external protocols from tags like IFRAME. There’s just no reason to allow them. That wouldn’t have fixed this vulnerability, but it would have reduced its severity greatly. It is harder to exploit this hole when the user must click.

Another potential solution is to use a whitelist of allowed protocols (See bug 173010). All other protocols would get blocked. But what happens to our precious convert from IE, who clicks on his ed2k link but sees nothing because ed2k isn’t in the whitelist? Or the GNOME user, who expects all of gnome’s silly little protocols to work when he types them into the address bar? Any Mozilla with a whitelist would quickly become out of date as new protocols became important; the Mozilla developers would be swamped with maintaining an ever-growing list.

The reporter of the blacklist bug then modifies his strategy in a later comment, saying that if a link referring to an external protocol handler is clicked, Mozilla should pop up a warning box. Now he’s on to something.

But what happens in this new case, if we are using a blacklist? The user clicks on a malicious link. Mozilla pops up a warning dialog. The user thinks, “I want to go to that link. Let me click OK without reading the warning first.” The user has now been infected, even though the fix stated in bug 167475 has been implemented.

This confirmation dialog could have been included in the whitelist plan as well. Unfortunately, that puts us into an even more dangerous position: with just a whitelist, the user would see the same dialog for a (dangerous) shell: link as for a (benign) ed2k: link. Inevitably many Mozilla users would accidentally accept the shell: links. On the other hand, Mozilla should get confirmation from the user whenever it is about to launch an external program. I would appreciate the notification, and it wouldn’t make me less secure.

Which brings me to my proposed solution:

1. Block external protocol handlers from tags like IFRAME where they do not make sense. (See bug 167475)
2. Continue to utilize a blacklist of known dangerous protocols. Do not allow Mozilla to trigger them. We can’t give users the option of using known-dangerous protocols, because they will inevitably find a way to use them. (Implemented in bug 163648)
3. Implement a whitelist of known-safe protocols. This should include protocols Mozilla handles along with ones needed for GNOME integration. (See bug 173010)
4. Create UI so that if a protocol is not on the blacklist or the whitelist, Mozilla prompts the user as if it were about to open a helper application. (See bug 167473) Malicious links will inevitably be accepted by many, but the confirmation will stop many more.

Even with this solution, Mozilla still would have been vulnerable to the latest attack. “shell:” was not on the blacklist (and it certainly would not have been on the whitelist.) Users would thus see a confirmation dialog for opening the link. The careful ones could avoid infection, but many would simply click “OK”. Which brings me to my most important gripe:

Get automated critical updates working!

Had the Critical Updates system been functioning at the time of the exploit, its severity would have been minimal, even with only a blacklist. Thankfully, the developers are hard at work getting it up and running. (Or is it working already? I never saw a critical update for the vulnerability. Did anyone else?)

I made my first post about the shell: exploit because I thought Mozilla deserved credit for their open development process. With that process so open, I’ve found that it’s also much easier to find areas of weakness — and that’s a plus. With constructive criticism from the outside, the process can change due to changing needs. I hope the Mozilla team gives itself a pat on the back for its handling of the shell: vulnerability, but I also hope that it will be more responsive to the long-term security holes that many users often point out.

Update: I have created an additional document that points out some failures surrounding this security hole. It should balance well with this post.

I’ve had many conversations lately about the security policies surrounding the Mozilla family of web browsers. The number of people fed up with the terribly vulnerable Internet Explorer has reached a critical mass. Now they want to know why Mozilla is better.

I suggest that those people who think “If IE is so bad, then Mozilla probably is too” take a look at this timeline. It tracks the identification, fixing, and notification of a potentially serious security hole affecting all of the Mozilla Organization’s consumer applications: the Mozilla Suite, the Firefox browser, and the Thunderbird e-mail client. I compiled it using the same publicly accessible, easy-to-find pages that Mozilla developers use all the time.

Here we go:

July 7 - 13:46 GMT - Keith McCanless files a bug in the Bugzilla Database reporting a new vulnerability. It exploits the windows “shell:” handler and allows a malicious web page to execute a program on a client’s computer (The program has to already be present on the computer). McCanless notes that the bug is “BOTH a security concern and a DOS,” since if the link points to a nonexistent file, it makes the Mozilla browser spawn off endless amounts of new windows. The bug is marked private since it is security-related; only developers with proper clearance can see it. (source)

July 7 - 16:26 GMT - Josh Perrymon sends the first e-mail to the “Full-Disclosure” mailing list about the vulnerability. (He presumably reported this bug independent of Keith McCanless.) The mail states that Mozilla will execute programs when passed the proper shell: URL. The vulnerability is now known to the world, ready to be exploited. (source)

July 7 - 18:16 GMT - Mozilla developer “timeless” creates patch closing vulnerability. He posts the patch on the Bugzilla Database so that other developers can approve it. (source) The bug had been known to the world for a matter of hours before a patch was created to fix it

July 7 - 18:19 GMT - Mike Shaver gives the patch a “superreview” flag, which is effectively a “thumbs up” for merging the code into Mozilla. The code may now be checked in to the Mozilla development and stable branches. (source)

July 7 - 18:55 GMT - Patch checked in to Mozilla development branch. (source)

July 7 - 18:58 GMT - Patch checked in the Mozilla Suite stable branches for versions 1.4 and 1.7 (source)

July 7 - 19:25 GMT - Back on the “Full-Disclosure” mailing list, Andreas Sandblad notes that the exploit “is dangerous” and explains how an attack might work (source)

July 7 - 22:07 GMT - Patch checked in to “Aviary” (Firefox and Thunderbird) branch (source)

July 8 - 01:59 GMT - Patch checked in to a new Mozilla branch; this branch represents the code for the new version, 1.7.1. Developers will then download this code and compile a new, secure version of the Mozilla Suite. (source)

July 8 - 03:23 GMT - A new branch is created, out of which developers will build new versions of Firefox and Thunderbird. The patch is checked into this branch. (source) In less than 11 hours after the vulnerability was reported to the public, all up-to-date Mozilla code was secure

July 8 - 10:56 GMT - Developers place binaries for Mozilla 1.7.1, the new secure release, on Mozilla FTP site. (source)

July 8 - 13:30 GMT - Thunderbird 0.7.2 binaries placed on the Mozilla FTP site. This release contains the patch for the security hole. (source)

July 8 - 14:13 GMT - An XPI “add-on” is uploaded that allows Mozilla Suite users to patch their browser without downloading an entire new release. (source)

July 8 - 14:27 GMT - Firefox 0.9.2 binaries placed on the Mozilla FTP site. This version contains the security patch. (source)

July 8 - 15:13 GMT - Thunderbird XPI “add-on” package placed on FTP site. This fixes the bug without requiring Thunderbird users to download an entire new setup file. (source)

July 8 - 16:13 GMT - Firefox XPI “add-on” package placed on FTP site. Once again, this fixes the bug without making users download a whole new setup file. (source) Before the vulnerability was known to the public for 24 hours, Mozilla had released updated versions of its poducts and patches for users running previous versions

July 8 - 17:38 GMT - Asa Dotzler opens the security bug to the public. Now anyone can go to the Bugzilla page and see the details of the vulnerability. By this point, however, patched versions of all affected software were available, and the bug had already been disclosed to the public on the “Full-disclosure” mailing list. (source)

July 8 - 20:53 GMT - David Baron updates the Mozilla.org main page so that it links to fixed copies of the Mozilla Suite, Firefox, and Thunderbird. (source)

July 8 - 21:57 GMT - Asa Dotzler checks in an official Mozilla.org notice of the vulnerability and the fix (source) In the course of less than a day and a half of public vulnerability, all Mozilla versions were updated, a security note was released, and new downloaders were secure by default

I think the Mozilla team deserves a round of applause for their speedy handling of a potentially serious problem. Furthermore, they have accomplished this feat in a transparent manner. And all at no cost to their users. From what I can see, most security bugs are handled this way, and that makes me happy to be a Firefox user.

Convinced? Get Firefox!

Oh dear lord. I was just about to eat some breakfast when I realized that this dream was too weird to lose.

My first memory of the dream is of walking down some underground path with, yes, you guessed it, Senator John Kerry. We’re walking through this tunnel-esque area, it’s almost like a forest, dragging some part that was the underside of his car. What?

So we finally make it out and I’m confronted with my own car. But some woman wants to borrow it. I let her do so, and meanwhile Senator Kerry runs off in the field. I note that he’s a really fast runner. Then I want my car back, so I take my keys back from the lady. I argue with her that it’s 5AM and I have a 9-5 job, so I need to get back home. Two girls run by: they are from an earlier part of the dream that I can’t remember (although no, it wasn’t that kind of dream).

Somehow or another I’m in a city driving. At some point I park the car. When I return to it, I find the contents of my pocket (e.g. wallet, keys) strewn about on the ground. I think time passes in the dream, so as all this is happening, it’s getting later and later in the morning, and I want to get to sleep more and more.

I have no idea how this transition happens, but I end up on a bus, progressing towards home. I wake up (I do that in my dreams, eerie) and realize that I’m completely naked. Thankfully I don’t think anyone saw me. The bus makes some kind of signal that the last stop is approaching. I frantically try to put on some clothes before the bus stops. Then I wake up.