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.

This entry was posted on Saturday, July 10th, 2004 at 3:30 pm and is filed under Mozilla. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.