Seems the Malware makers aren’t wasting any time getting around to trying to exploit users of Mozilla browsers. So much for the security through obscurity concept.
Over the past few months, it has become apparent that many authors of malware (a category of malicious software that includes viruses and spyware) have started targetting Mozilla users. While it is not believed that any attackers have managed to exploit the XPInstall mechanism to install software without the user’s consent, several sites have tried tricks such as repeatedly asking to install an XPI package when a page loads, taking advantage of the fact that many users will accept the installation to make the dialogues go away.
Fortunately, users of recent Mozilla-based browsers now enjoy several new security safeguards designed to protect against these sorts of attacks. During the 1.7 release cycle, Daniel Veditz developed a patch that blocks XPI installs from being triggered by a page load, preventing software installation dialogues from appearing as soon as a user visits a site (bug 238684). Later in the same release cycle, a whitelist of sites that are allowed to ask the user for permission to install software was implemented (bug 240552). The default whitelist for Mozilla 1.7 features mozilla.org, mozdev.org and texturizer.net (home of Firefox Help and Thunderbird Help). Mozilla Firefox 0.9 just allows update.mozilla.org (though this has since being expanded to the whole of mozilla.org).
The most recent Firefox nightlies feature a new user-interface to manage the XPInstall whitelist. When a user tries to install software from a site that is not on the whitelist, a thin non-modal yellow bar appears at the top of the content area, informing the user that the install has been blocked (bug 241705). A button allows the user to add the site to the whitelist if they choose. Testers of the beta release of Windows XP Service Pack 2 will probably find the yellow bar familiar: it’s almost a carbon copy of the new Internet Explorer Information Bar that appears when an ActiveX control is blocked. If you cannot wait for Firefox 1.0 to try this feature, grab a nightly build from the 0.9 branch but remember that there may be bugs.
Unlike Microsoft which tends to let a problem fester until it’s so widespread they can’t ignore it any longer, the folks behind Mozilla are responding already at the first sign of attempts to exploit their software. The problem isn’t so much that Internet Explorer has holes—all software has holes—it’s that it takes so damned long for Microsoft to patch them and they’re often reactive rather than proactive about it.
Oh and the target date for the release of Firefox 1.0 is Tuesday 14th September according to the recently updated roadmap. Currently it’s expected that there will be three release candidates before the final release.