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 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.
Saw the whitelist UI at work when I went to download Tabbrowser Extension's off the author's home page. Usually having to whitelist things gets under my skin, but I totally support this and love it dearly. It's a very sleek UI, too- just this tiny little bar at the top that I can ignore if I actually want the xpi blocked, yet still makes adding a site to the whitelist a two-click operation.
The Web Features Panel should be worked over IMO. Checking each option allows a web page to do more stuff. Only "Block Popup Windows" breaks this pattern. Also the Exceptions buttons next to "Allow web sites to install software" and "Load images" make it sound like they lead to a blacklist.
But I made a patch to rename the buttons for popup blocker and software install to "Allowed Sites..." and disable them if the corresponding feature is disabled in general. See <http://bugzilla.mozilla.org/show_bug.cgi?id=250543>
Having installed Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040707 Firefox/0.8 (which is actually Firefox 0.9.2), I still am able to install my own XPI splashes from <http://mithgol.pp.ru/Mozilla/>
What am I doing wrong then?
I'm pretty sure that you need the nightly build to see this new feature. It will be available in Firefox 1.0
Nightly Firefox: <http://ftp.mozilla.org/pu…refox/nightly/latest-0.9/>
Are you absolutely certain that build is really what you think it is? An 07/07 build that's equivalent to .9.2 should identify it as .9+, not .8
Make sure it's off either the AVIARY branch (the one leading up to 1.0) or the .9 release branch, and not off the trunk or some remainder from the .8 release branch.
1. Get a new branch nightly. This is brand new. I'd suggest to wait for today's as Ben has just checked in additional tweaks. 2. Uninstall/rename/delete the application directory before installing to get the correct version string.
"Mozilla Firefox 0.9 just allows update.mozilla.org (though this has since being expanded to the whole of mozilla.org)."
Allowing the whole of mozilla.org is a bad idea because bugzilla.mozilla.org can allow anyone to upload a malicious XPI
#7 Re: Need help? Do it yourself
by lacostej <email@example.com>
Tuesday July 13th, 2004 1:36 AM
good point. fixed.
A question arises: when will the extensions from update.mozilla.org get signed? Then we could have some trusted keys, and an options to only install signed extensions....
Yes! I hope that gets done before 1.0 is released. It doesn't look good to have a security patch (the shell bug) that gives you a warning that it's unsigned.
Besides that, these new security safeguards sounds great!
Keep up the good work Mozilla people - thanks for taking back the web ;)
Important especially given the frequency that malware messes with the host file. Granted, you can't really trust anything once your computer has been infected, but changing the host file is so easy.
Would it be possible for Mozilla to query a DNS server directly to verify that the IP given by a clean DNS server is the same as what is being returned by the client when allowing a whitelisted site to do potentionally damaging things?
Not really. It could be done, but it wouldn't work for people using proxies, and it would mean you'd have to configure Mozilla for your ISP, which would cause all kinds of problems.
You could have it check the DNS stuff with some kind of central authority, but that's effectively doing the job that signing does.
Does that little bar (as in <http://www.bengoodger.com/software/mb/blocked.png> ) stay there all the time until I click "Allow"? Shouldn't there be a "Deny" button or something that removes the bar? ...or does it auto-hide after a while?
Hum... looking at the screenshot I see it's way too inviting to click on the "Allow Themes" button without any other option. There should be another option to close that warning... if not, even if it's timed, I can see many people clicking on the only button they see just because it's the only option.
Yep I agree, put a message on the web page telling people to click on the accept button for a better browser experience and a bunch of them will. I think a less obvious icon like the popup blocker has would be a better way to go with this, less invasive, doesn't really matter if it's a few more steps (how often are you going to use it ligitimately), and hopefully less obvious to an unexperienced user (the sort of person who would need protecting from this sort of thing). I can't tell you the number of people that are suprised when I tell them I actually read the licence agreements before I click yes, and don't just treat them as unavoidable click through annoyances - if this ends up feeling like one of those click here please type things for most people, it'll do very little to really protect people from themselves. I know that a webpage could also instruct them how to allow it even if it was in the popup type format, but I think the extra steps and the more space that a dialoge can give can mean that people take it more seriously than a simple "click ok to get rid of this message" type thing.
Just my thoughts on it.
is mozdev.org going to be added?
they said: "During the 1.7 release cycle, Daniel Veditz developed a patch"; then later they said: "Later in the same release cycle". do we know WHERE in the 1.7 cycle these got included? (1.7B,1.7rc1,1.7rc2,1.7rc3,1.7final,1.7.1) ? i am very curious which release(s) include these upgrades for the suite. thanx 4 any info :)
#21 Re: Moz-1.7 question
Tuesday July 13th, 2004 1:57 PM
Even when you are developing a patch during the 1.7 cycle, the patch must not be included to that branch. As that is a new feature, it will be included in HEAD for testing first before a new feature comes to a stable branch. Try your luck there...
are you saying this "patch" (or feature or whatever) is not even included in 1.7.1 ?? :( *sniff* they had said: "users of recent Mozilla-based browsers now enjoy several new security safeguards..." notice the words "recent" and "now enjoy"... they make it sound like it already is in 1.7.1 (though not clear if 1.7final or 1.7rc3 enjoyed the same)
#29 Re: Re: Re: Moz-1.7 question
Wednesday July 14th, 2004 3:49 AM
He's saying that whatever happened with the 1.7 branch, the patches will definitely be in trunk builds (including 1.8alpha1), which is true, but it doesn't answer your question.
The blocking of automatic "onload" installation was checked in on 20th April, so that would have been in 1.7RC2 (and later). The whitelist went in later, and is in 1.7RC3 and later.
OK | Install (two options instead of one.)
or the stronger version:
OK | Install Anyway.
OK closes the warning. Install Anyway installs the XPI with the usual XPI install prompt.
Is this good enough?
The only other option is that the first time an XPI is blocked, like the first time a pop-up is blocked, a modal explanatory window appears.
But in general, a novice user would not notice a non-modal display like this. We'll get more usability data when SP2 goes widespread. Tweaking the interface from SP2 should not happen unless we genuinely disagree with it, or think Microsoft is interested in patenting that interface in order to harm Mozilla.
In addition, the no XPI install on pageload patch should be enough to solve abuse. The existing XPI prompt is warning enough.
> 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"?
I totally agree with you on this. If the feature is going to stay, then I'd say to have a close button, and have something like a "Don't ask me for this site again" type of a checkbox that you could also pick.
If you want to get into MS screwing up how webpages are going to display, take a look at longhorn (The next Windows version... 2006) The sidebar and other "features" of the UI are huge.
#36 Re: Re: UI refinement
Sunday July 18th, 2004 1:31 PM
"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)."
The screenshot is out of date. The user has to press a button, which opens a dialogue where they can add the site to the whitelist. They then have to add the site, press OK and repeat whatever action triggered the software installation in the first place. I can't see it being easy for a site to trick them into doing that.
#26 What about signing the XPI packages?
Tuesday July 13th, 2004 7:16 PM
Are the XPI packages signed somehow? I would think having a GPG signature would be a good thing.
#35 Re: What about signing the XPI packages?
Wednesday July 14th, 2004 3:32 PM
The packages aren't currently signed. The facility exists (and Mozilla informs the user that every package is unsigned), but it's not used currently.
This type of proactive approach and understanding of security is why I love Mozilla. Way to go everyone involved on this particular feature.
It's good, but it's not really "proactive" (unless you're mis-using the word as many people do these days just to mean "active"). As the article says, these steps are being taken now as a reaction to the appearance of malware over the past few months.
It's good that they're reacting quickly and effectively though.