Malware Authors Target Mozilla, Developers Respond with Enhanced Safeguards

Monday July 12th, 2004

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, and (home of Firefox Help and Thunderbird Help). Mozilla Firefox 0.9 just allows (though this has since being expanded to the whole of

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.

#24 Re: UI refinement

by jgraham

Tuesday July 13th, 2004 3:31 PM

You are replying to this message

> Is this good enough?

No. The close button should be labeled 'Close' not 'OK'. I'm not sure why this is considered good UI in the first place. It's intrusive, it looks like it will shift the content down, it draws attention to the blocked install every time the page is visited (and if a page can find a way to repeatedly bring the bar up, e.g. trying installation on every link press, would quicklyly annoy people into clicking allow) and it's not clear (from the screenshot) how it deals with the ssues in bug 162020 (if one can somehow get a user to unwiittingly click 'allow' as soon as the bar comes up, they may accdentially grant extra permissions).

Can someone justify this nonstandard UI beyond "we're copying whatever IE does"?