346960 - Make it harder for malware to install extensions into Firefox

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, enhancement)

Description

[Ben Dover]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.5) Gecko/20060719 Firefox/1.5.0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.5) Gecko/20060719 Firefox/1.5.0.5

See Extra

Reproducible: Always

Steps to Reproduce:
1..
2..
3..

Actual Results:  
.

Expected Results:  
.

I bevlieve we should implement some sort of security mechanism for the extension theme manager.

According to this article http://www.mozillazine.org/talkback.html?article=12722
this virus "FormSpy installs itself in Firefox by directly modifying Firefox user profile files, completely bypassing the standard Firefox extension installation mechanism (and warning messages)."

What we should do is only have the extension being ran IF it was downloaded thru firefox. 

How

When the user as the extension warning show up, maybe also have it take a snapshot and md5 sha1 the file then allow the user to download the xpi file.(The snapshot could also be taken at the end of the download)
Now when the user is requested to restart have him and restart.

When firefox starts up again, it should check against a file of known snapshot md5 sha1 database of known LEGIT extension installations. If an extension is found in the extension folder but not in the database of known LEGIT extensions installations, have the extension disabled or even not loaded.a

I may resume work on this but for rightnow i think this is a very good indea, ive been hit with two viruses now then install extensions completely bypassing FF security.

Comment 1

[Steve England [:stevee]]

Dupe of/related to bug 219180 and/or bug 262762?

Comment 2

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

Once a process is running on a system they could disable the code that performs the check or just attack from another vector. This really needs to be solved at the OS level before the system (e.g. anything that stops code from running on the OS like real-time anti-virus, firewall, etc.) has been compromised otherwise it is just a war of attrition where we close one attack vector and they choose another.

Comment 3

[Benjamin Smedberg]

Agreed. Once an attacker has access to the filesystem, we don't stand a chance.

Comment 4

[Ben Dover]

""war of attrition where we close one attack vector and
they choose another.""

Then we shouldn't issue patches to users then. I mean what would the point be, its the same situation here, if we close one attack vendor they will choose another so why patch products then?

By The Way, thank you for closing my bug that I was going to work on! I appreciate the fast closing!

Comment 5

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

There are attack vectors that we are responsible for that can compromise a system which we will continue to patch and then there attack vectors that we aren't responsible for like this one. They are significantly different.

Comment 6

[Daniel Veditz [:dveditz]]

The "formspy" thing installed as a profile extension, it did not hack the Firefox install itself. This is a perfectly reasonable thing to try to protect against.

Assuming an admin locks down the Firefox install dir (so spyware can't corrupt our checking code) how can that admin keep their users from getting hacked from rogue extensions installing into the profile?

Throwing stuff out here:

- a lockable pref (via CCK) that says "no profile extensions, period"

- the same, but with a list of allowed extensions by guid. Maybe the list itself lives in a text file (in the read-only install dir) rather than listing each in the prefs. Or all prefs, not sure about the memory footprint tradeoffs here.

- A startup confirmation dialog when we find an extension that isn't yet installed, giving the user a chance to cancel and remember that choice for that extension. Malware could work around this by hacking into extensions.rdf, but having to implement .rdf might weed out the trivial attacks. In addition anti-spyware apps with a resident component (MS's anti-spyware, Spybot's "tea-timer", etc) can be taught to watch for changes to that file and alert on it just as they do for changes to important windows registry keys.

Probably other reasonable things you could do for this scenario.

Comment 7

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

Ok, but I am not sure why it is reasonable to protect against a profile extension from being installed and it isn't reasonable to protect against app chrome or app extension from being installed. One could require admin privileges and the other could be a normal user account but IMO that is not a valid reason for protecting against one and not the other from a local process performing an installation. Also, I believe a power user installing a program that contains malware can be granted elevated privs where it is possible to write to these directories.

Comment 8

[Daniel Veditz [:dveditz]]

(In reply to comment #4)
> Then we shouldn't issue patches to users then. I mean what would the point
> be, its the same situation here

The security issues we are primarily concerned with and issue patches for are remote attacks, not the same situation at all: high exposure to potential attacks, more limited and protectable attack surface.

Comment 9

[Daniel Veditz [:dveditz]]

(In reply to comment #7)
> I am not sure why it is reasonable to protect against a profile
> extension from being installed and it isn't reasonable to protect against app
> chrome or app extension from being installed.

We could do the same for newly discovered app chrome and extensions -- I think it's a great idea, since it *will* make attackers have to work harder, weeding many of them out (for a time). But ultimately less effective protection because if you can modify things in the install dir you can defeat the checking code. That's the arms race.  The bad guys can ultimately outspend us on the arms race, but if we can take the first couple of fairly cheap steps and forestall attacks until we can get the anti-malware apps to pay attention to securing Firefox from unauthorized changes the way they do IE settings then that might be worth the investment.

> Also, I believe a power user installing a program
> that contains malware can be granted elevated privs where it is possible to
> write to these directories.

They can indeed, but at that point that power user is screwed. But on a locked-down corporate box an unpowered user won't be allowed to screw themselves that way, but their profile is still writable.

Comment 10

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

(In reply to comment #9)
> (In reply to comment #7)
> > Also, I believe a power user installing a program
> > that contains malware can be granted elevated privs where it is possible to
> > write to these directories.
> 
> They can indeed, but at that point that power user is screwed. But on a
> locked-down corporate box an unpowered user won't be allowed to screw
> themselves that way, but their profile is still writable.
From consulting I can comfortably state that the vast majority of companies provide power user privileges so their users can install apps with the exception mainly being financial institutions. My point with my previous statement is that if we are going to try to close this vector it would be IMO more appropriate to try to close the app chrome and app extension vector using the same methodology since I am quite sure that our Win32 user base of locked down systems is extremely small.

Comment 11

[Dave Townsend [:mossop]]

A few random thoughts:

From support channels I have seen more incidents of things installing themselves into the application chrome than as extensions in the profile folder (The MyWebSearch toolbar is a prime example that causes numerous problems).

Where does the extension blacklist fall here. Surely if we have rogue extensions installing themselves into the profile that are doing bad things then they should be blacklisted.

Using purely extensions.rdf to record "valid" extensions really is a trivial measure. Sure parsing rdf is hard, but you don't need to parse the rdf, just add a set of prepared RDF:Description entries to the end. I imagine about your only option is an encrypted file based on the user's master password (so they have to set one for it to be truly secure). Of course I'm guessing that that'd incur a nasty startup time regression.

Just to add, I'm sure it would have been considered anyway, but please remember the extension developers. I'm sure many like me routinely manually install and update extensions in their profile dir without Firefox running. Lets not make any implemented warnings too much of a pain in the neck for them.

Comment 12

[Dave Townsend [:mossop]]

Rather amusingly, a while after my last comment I finally discovered the cause of my Firefox crashing whenever I right clicked on a webpage. Turns out a download manager I had installed a short time ago installed an extension into my profile without me knowing about it.

Also it appears that the latest Skype version will do something similar: http://forums.mozillazine.org/viewtopic.php?t=456147

Comment 13

[Daniel Veditz [:dveditz]]

> Surely if we have rogue extensions installing themselves into the
> profile that are doing bad things then they should be blacklisted.

Not very useful. First, as you note, are the non-extension chrome things like MyWebSearch toolbar: not covered by the blacklist. Second, rogue extensions will quickly figure this out and simply use random GUIDs or re-use the GUIDs from the Yahoo and Google Toolbars or other legit extensions (the recent "FormSpy" actually did this, though not likely as a blacklist-avoidance technique). We've got a short window when the blacklist might work as a surprise-attack against rogue extensions, but that's about it.

The blacklist is good for well-intentioned extensions that are vulnerable or broken (run-away server pings, for example). Or maybe slimy adware that's trying to appear legit but still crosses the line, except those guys would probably sue us.

> Using purely extensions.rdf to record "valid" extensions really is a trivial
> measure. Sure parsing rdf is hard, but you don't need to parse the rdf, just
> add a set of prepared RDF:Description entries to the end.

And find and update the urn:mozilla:item:root list, but yeah, pretty trivial.

But apps who modified this file directly would clearly be doing slimy unauthorized things, and a major benefit here is the potential for anti-malware apps to monitor that file for changes. Although maybe it's just as easy to watch the whole profile.

Comment 14

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

*** Bug 353395 has been marked as a duplicate of this bug. ***

Comment 15

[Jesse Ruderman]

*** Bug 219180 has been marked as a duplicate of this bug. ***

Comment 16

[Jesse Ruderman]

This is so WONTFIX.  "Fixing" it would hurt legitimate users more than malware authors.

Comment 20

[joopbraak]

Guys, this really IS an issue. I don't understand you underestimating this. 

How hard is it to build in an extra security measure like:

"This application wants to install an Firefox extension? Is this what you want to do? Yes/No"

Comment 21

[Dave Townsend [:mossop]]

(In reply to comment #20)
> How hard is it to build in an extra security measure like:
> 
> "This application wants to install an Firefox extension? Is this what you want
> to do? Yes/No"

For a well behaved application? Not very hard. That is what bug 476430 is going to work on. But malware generally isn't well behaved and whatever measures we might put in place can be circumvented.