Mozilla and security

Linux users, as usual, sit back and feel smug. We don't run Internet Explorer, and our browsers, being free software and thus inherently more secure, will not present us with this sort of unpleasant surprise.

Right?

As free browsers continue to grow in popularity, they will also attract more attention from the inhabitants of the darker side of the net. So it is worth looking at how Mozilla, which is the core of many free browsers, deals with security incidents.

Linux users may well have missed this security advisory that went out on July 7, because only Windows users are affected. For those users, however, the impact of this bug could be large. Essentially, Mozilla-based browsers (including Firefox and Thunderbird) pass "shell:" URIs directly to the operating system, which happily runs the command included in the URI. It is a direct path to a command interpreter on the local system; all it requires is getting the user to click on the wrong link.

Some commenters have said that this is really a Windows bug; Mozilla is just passing on the URI and Windows decides how to deal with it. But that is an evasive answer; a security-conscious application must sanitize any externally-supplied data that it passes on to the system. This vulnerability is a Mozilla bug; it was closed by having Mozilla do the checking it should have done in the first place.

Others have complimented Mozilla for its quick response: a patch was available about one day after the vulnerability was posted. This response time has been favorably compared with the rather slower pace characteristic of Internet Explorer fixes. The only problem with this point of view is that the Mozilla developers have known about this issue since 2002; Mozilla bug 163767 suggested the addition of a preference which would disable the use of external protocol handlers. The bug remained open for almost two years, however, until the project had no alternative to fixing it. It seems that developers of free software are entirely capable of sitting on a vulnerability in the absence of an immediate exploit threat.

The point here is not to flame the Mozilla project for shipping code with a vulnerability, or even for not realizing the importance of a known hole. These things happen, and Mozilla's record is better than that of many other projects. The point is that we cannot assume that, by accessing the web with a free browser, we are immune from exploits. Vulnerabilities are a fact of life, and the incentives for finding and exploiting vulnerabilities in free browsers are growing.

In that context, it is encouraging to see this MozillaZine article which talks about some recent changes made by the Mozilla hackers. The Mozilla extension mechanism is a powerful way of adding new capabilities to the browser, but it could also become a mechanism by which attackers load hostile code directly into target systems. It should, thus, be hard to add an extension; it shouldn't happen automatically. The Mozilla hackers have noticed an increase in attempts to load unwanted extensions, and have responded with some new mechanisms designed to block those attempts. These include a whitelist of sites allowed to propose the addition of extensions.

One should also note this vulnerability which could be of use to the perpetrators of the increasing number of "phishing" attacks out there. Through the use of some Javascript and frames trickery, an attacker can falsify somebody else's page while having the location bar show a legitimate URL. Internet Explorer is vulnerable, but so is Mozilla. (Thanks to Chester Young for the pointer).

With luck, the Mozilla hackers (and khtml hackers too) will increasingly keep security in mind as they write their code. And we know they will fix problems quickly when they become apparent. But we cannot assume that our free browsers are immune from security problems; the world is, sooner or later, going to prove otherwise.