250854 - XPInstall Permission Manager: Blacklist feature

Status: RESOLVED WONTFIX

(Firefox :: Settings UI, enhancement)

Description

[Prognathous]

Judging from the way many clueless IE users handle ActiveX installation dialogs,
it might be a good idea to not even display the dialog/toolbar (from Bug 241705)
if a site has bad track record. This can be done using a predefined list of
blacklisted domains (not that there are any at the moment). 

The logic may be as follows:

- If a site is whitelisted -> Allow XPI installation
- If a site is blacklisted -> Disallow XPI installation and display an
informative dialog if the user attempts to install an XPI (perhaps add an icon
in the statusbar as well).
- If a site is not listed in either of the above -> Display the UI from Bug
241705 and let the user decide.

It's probably only a matter of time until Mozilla-hostile sites are found.
Having this blacklist would provide a good infrastructure for mozilla.org to
release official releases that already come with a predefined blacklist that
protects users against such sites.

For reference, you can find a very extensive list of IE-hostile sites here:
https://netfiles.uiuc.edu/ehowes/www/res/ie-spyad.zip

Prog.

Comment 1

[Robert Parenton]

Doing this may have legal implications, however.  Also, who would maintain such
a list?

Comment 2

[Prognathous]

(In reply to comment #1)
> Doing this may have legal implications, however.

Such as?

>  Also, who would maintain such a list?

The same people who maintain the security of the browser via code patches.
Reports of sites which distribute hostile XPIs are not much different than
reports of other security related issues - b.m.o is the right place for both.

Prog.

Comment 3

[Robert Parenton]

I'll use Gator (or whatever it's called now) for an example.  Technically they
have use a legal method to get their software on people's computers, and people
must agree (usually by not reading the license and just clicking ok) to install
Gator.  It seems possible that if they were blacklisted by default that they
could argue that Mozilla/Firefox is impeding their ability to do business.

Just a thought.  I believe someone raised that concern and explained it better a
while back in some other bug.

Comment 4

[Prognathous]

Note that I'm not suggesting to blacklist websites for mere suspicion. In order
for a site to be blacklisted, it has to be involved in some serious wrong doing,
e.g. proven and well documented distribution of malware that originates from
specific domains.

Having an easy to manage blacklist in advance, would prevent Mozilla-hostile
XPIs from becoming an on-going threat (and I'm sure that they will come into the
scene sooner or later).

Imagine the state of Windows security had Microsoft implemented WinXP-SP2
components and tweaks earlier. We should definitely not repeat their lack of
foresight.

Prog.

Comment 5

[Robert Parenton]

I guess I misunderstood a bit, and it probably is a good idea.

Now a implementation question that will have to be answered sooner or later: 
What list should take priority over the other, the whitelist or the blacklist? 
I can think of reasons supporting either case.

Comment 6

[Prognathous]

(In reply to comment #5)
> What list should take priority over the other, the whitelist or the blacklist? 

IMHO, the latter. Security issues in IE are the number one reason for the flocks
of recent converts. I'd rather go for security over convenience here. It totally
acceptable to make users go through hoops to enable a site that is blacklisted
by default. After all, what good can come out of it?

The whole concept of this RFE is to make sure users (mostly clueless ones) don't
get hit by inadvertently allowing XPI from hostile sites. To facilitate this
goal, the blacklist should have top priority.

Prog.

Comment 7

[Prognathous]

We've just got a report at mozilla.org.il forum from a user who encountered what
is very likely to be a hostile XPI. Hebrew speakers can read the thread here:
http://www.mozilla.org.il/board/viewtopic.php?t=1076
Those who don't read Hebrew should look at this screenshot:
http://images.nana.co.il//Upload/72004/ForumMessageAttachments/ForumMessageImage_515952.JPG

This is not an isolated case. Other sightings of hostile XPIs are mentioned in
the following pages:
http://forums.mozillazine.org/viewtopic.php?t=64341
http://forums.mozillazine.org/viewtopic.php?t=66531
http://bugzilla.mozilla.org/show_bug.cgi?id=238684

Here's a translation of the steps needed to recreate this problem:

1. Open http://www.andr.net
2. In the search field, type mozilla (or any other string that will return results)
3. Click any of the search result. A dialog box will appear: "You must click YES
to download this crack.". Click Yes a few times, until the dialog is gone.

I can't reproduce it from my workplace, due to filtering software that blocks
parts of this site, but I'll try to do it later today from home. On to the next
step:

4. An XPI installation dialog should appear, suggesting to install "Free Access
Plugin", whatever that is. There's no doubt that at least some clueless users
are bound to accept this installation.

All the above mean that homepage highjacking and other evils are on their way to
hit Mozilla. Implementing the pre-defined blacklist that this bug asks for would
minimize the potential damage that such sites can cause.

Prog.

Comment 8

[Daniel Veditz [:dveditz]]

Prog: you don't need to "sign" your comments, your name is listed at the top of
each block.

The back-end already supports blacklisting. A site cannot be both blacklisted
and whitelisted at the same time, there is a single install entry in the
permission manager with two separate values.

http://lxr.mozilla.org/mozilla/source/xpinstall/src/nsInstallTrigger.cpp#366

Comment 9

[Lincoln Ramsay]

I would like to see this feature even without the predefined list of blacklisted
sites. I might need to use a site on a regular basis that causes infobars to
appear and that's annoying. Being able to prevent software install from a site
lets me avoid seeing all the info bars.

It should be combined with the whitelist dialog. Similar to how you can save
passwords, not save passwords or never save passwords for sites.

Comment 10

[Daniel Veditz [:dveditz]]

(In reply to comment #9)
> I might need to use a site on a regular basis that causes infobars to
> appear and that's annoying. Being able to prevent software install from a site
> lets me avoid seeing all the info bars.

You can go to about:config and create a new string pref
"xpinstall.blacklist.add" containing the domain you want to blacklist. just
"www.foo.com", not "http://www.foo.com". This will eventually revert to a blank
string, the real list is in your profile hostperm.1 file.

This doesn't help anyone else, we do need UI for the average person.
> 
> It should be combined with the whitelist dialog. Similar to how you can save
> passwords, not save passwords or never save passwords for sites.

Comment 11

[Przemyslaw Bialik]

(In reply to comment #10)
> You can go to about:config and create a new string pref
> "xpinstall.blacklist.add" containing the domain you want to blacklist. just
> "www.foo.com", not "http://www.foo.com". This will eventually revert to a blank
> string, the real list is in your profile hostperm.1 file.

hmm this works but there are some issues:
1. If I'm blacklisting site I'm expecting that it would not annoy me with
infobar (currently it looks like the site would not have any entry in permission
manager)
2. Blacklisted site has 'Block' status and when you press on Allow button it
would change the state to 'Allow' but after relaunching the permission manager
the site is again in 'Block' state - it can be allowed by removing first it's entry.
3. UI stuff - add second button to block sites or let allow one switch to block
if the highlighted site is allowed and the opposite (allow would be the default
one when adding sites).

Comment 12

[flock31070]

I don't think blacklists are necessary, except for cases like ad-blocking where there are common websites/advertisers that don't change their URL like doubleclick/burstnet...

What kind of popular sites would need to be blacklisted?

Comment 13

[Prognathous]

(In reply to comment #12)
> What kind of popular sites would need to be blacklisted?

The kind that host hostile-XPIs.

Prog.

Comment 14

[Robert Strong (they/them - no direct email)]

As comment #8 states this is already available in the backend code but there is no ui to accomplish this. To add this to the ui does not requires any Extension Manager work and as a matter of fact the Extension Manager never uses the whitelist or blacklist code - the whitelist is checked by XPInstall prior to it handing the extension off to the Extension Manager for installation.

What remains here is ui work in the pref panel to provide disallow in a similar manner as we provide allow. Changing component to Preferences

Also, there is bug 318338, bug 271166, and bug 300289 for centralized blacklisting which is completely separate from the permission manager and this bug.

Comment 15

[Prognathous]

(In reply to Robert Strong, comment #14)
> Also, there is bug 318338, bug 271166, and bug 300289 for centralized
> blacklisting which is completely separate from the permission manager and this
> bug.

Actually, this bug isn't focused on letting users define the blacklist themselves, nor does it suggest blacklisting specific extension IDs. What it does suggest is using a locally stored blacklist of sites and hosts (not extensions) with known malicious history. Keeping this type of managed blacklist locally has two advantages:

1. It protects against unknown extensions that have a higher likelihood of being hostile (e.g. those from www.evil.tld and other sites/hosts on the blacklist)
2. It is effective even if a central on-line blacklist is down for any reason.

Needless to say, this blacklist should be updateable, just like virus definition files are.

Prog.

Comment 16

[Robert Strong (they/them - no direct email)]

(In reply to comment #15)
Understood... I was just pointing the other bugs out for reference along with my other comments.

Also, the current whitelist and blacklist are both updateable though there is no ui for the blacklist.

btw: the centralized extension blacklisting will store a file locally that will still be used if the site is down.

Comment 17

[Prognathous]

(In reply to comment #16)
> Also, the current whitelist and blacklist are both updateable though there is
> no ui for the blacklist.

Is there currently any mechanism that updates this blacklist? Is there anyone at the Foundation responsible for keeping the master blacklist up-to-date?
 
> btw: the centralized extension blacklisting will store a file locally that will
> still be used if the site is down.

That's good to know. Is the blacklist based on sites/hosts or extension IDs? I think the latter is too easy for hostiles to overcome.

Prog.

Comment 18

[Robert Strong (they/them - no direct email)]

(In reply to comment #17)
> Is there currently any mechanism that updates this blacklist? Is there anyone
> at the Foundation responsible for keeping the master blacklist up-to-date?
Only during an app upgrade (e.g. full install or partial from software update)... of course new installs would just receive the entire list of sites. As shown in comment #10 it is done by reading a pref, adding the sites, and clearing the same pref.

> That's good to know. Is the blacklist based on sites/hosts or extension IDs? I
> think the latter is too easy for hostiles to overcome.
No, the goal of extension blacklisting is different in that it is primarily to disable and prevent new installs of extensions which have been found to have security problems so we can't just prevent installs from sites.

Comment 19

[Mike Connor [:mconnor]]

So, I don't think this is really useful, since it basically nets out to "don't show the infobar for this site"  Do we really have otherwise-useful sites that offer unwanted xpinstalls?

I don't think so, but please reopen if there's cases where that's true...

Comment 20

[Daniel Veditz [:dveditz]]

We also now have malware-site blocking in FF3, so sites pushing truly malicious payloads shouldn't even get this far.

And another bit of support for wontfix: given current back-end support someone could have written an extension to do this but no one has thought it was worth doing. If we're going to incorporate new UI I'd rather it be for something tens of thousands of people think useful enough to go out of their way to install an extension for.