294484 - Don't allow external applications to install extensions without user's knowledge/approval

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, enhancement)

Description

[Jean-Marc Desperrier]

The feature in bug 293548 "Provide windows registry install location for
extensions" is very convenient, but it raises some disturbing security issues.

It's so easy to use that we can be certain spyware authors will start making use
of it very fast to silently install evil Firefox extension. It might have been
technically feasible before, but it was hard enough to protect us quite well.

A major part of that problem is only PR, the true culprit is the user who
allowed a bad application to create files/registry entries on his computer.

But when users see that the startpage of IE has been hijacked, their reaction is
to hate IE. They don't think that it's them who are the true responsible. We
don't want the same to happen to Firefox.

And there is one situtation where it can be really exploited as a vulnerability.

Many people today have started to use firewalls that filter outbound connexion,
so that even if the spyware can install itself on the computer, it will not be
able to phone home.
But if it succeeded in being installed as a Firefox extension, the firewall will
apply the Firefox rules to the spyware's connexions, and allow it to connect to
any host it wants.

Displaying a confirmation warning the first time Firefox is started after an
extension has been installed this way would alleviate the problem.
But only partially as users tend to always click OK.

There is another point that annoys me. When the extension is distributed as a
XPI, we have the architecture available to require digital signature in the
future. How would we do for extensions installed in this way ? I worry it
becomes a way to bypass the signature checking.

Comment 1

[Ben Bucksch (:BenB)]

Not a security hole.
Good points, though.

Comment 2

[Jean-Marc Desperrier]

Well, even if it can be considered it's not really a security hole, I was a bit
wary about discussing in the open how this install mechanism can potentially be
abused.

I think it's quite OK to have it in 1.8b2 like that, but that we need the
additionnal layer of confirmation for the final release.

Comment 3

[Caleb]

That's a great point.

But the same could be applied for XPI's dropped in the extension folder, no ?

I think that there should be a dialog that displays all of the extensions that
are about to be installed, and a checkbox for each extensions, unchecked by default.

Each extension will have its description and version (just like the EM shows)
and also the location from where it's installed. (possibly the name of the
installation file too)

At the bottom of the dialog you could have the following buttons: Select All,
Deselect All, Proceed with Install.

This way, no user will "accidently" press OK without knowing what he is going to
install.

Comment 4

[Oliver Saier]

I'd hate adwares to be able to overlay advert toolbars and such sh!te without
user consent.

Comment 5

[PikeUK]

What about dropping a jar into Firefox\chrome and adding a line to
installed-chrome.txt? Is there any reason for a malware author to use the new
EM-based installation methods when they can create an invisible, uninstallable
"extension" in that way?

Comment 6

[PikeUK]

(In reply to comment #5)
> ...they can create an invisible, uninstallable
> "extension" in that way?

Oops I meant an extension that can't be uninstalled (from the EM anyway) not one
that can.

Comment 7

[Jean-Marc Desperrier]

You have a point about the chrome, I thought it was harder to do.

Still it requires the spyware author to do some homework to find how those
mechanisms work, to localize the firefox directory, to be able to write inside
it (so this time some security mesures will be effective). Even if it's possible
to circumvent some of hat by using the profile directory instead.

Comparatively the method in bug 293548 will be publicly diffused making it an
obvious target. 

But we should indeed also think about a method to protect against external
fiddling of the profile/application. The adequate line of defense would be that
an attacker can't break the protection without patching the firefox executable.
If he has to patch the executable, then anti-virus and outbound firewalls can
detect it and act accordingly.

Comment 8

[Gervase Markham [:gerv]]

The malware author is running arbitrary code on the user's PC; we have therefore
lost.

Say we had a flag for each extension where the user was prompted "this new
extension has appeared - is it OK to install it" for new extensions installed
this way. The malware would just change the flag itself. 

If they've got control of your computer, there's nothing we can do to stop them
installing stuff silently, and we shouldn't break the user experience for
legitimate uses in a vain attempt to protect against the illegitimate ones.

Gerv

Comment 9

[Jean-Marc Desperrier]

(In reply to comment #8)
> The malware author is running arbitrary code on the user's PC; we have 
> therefore lost.

It's not exactly as clear as that. As already discussed, there can still be a
line of defense in the form of antivirus, and outbound firewalls.

> [...] we shouldn't break the user experience for
> legitimate uses in a vain attempt to protect against the illegitimate ones.

And that might be the most important part. It's not about breaking the user
experience.

If properly made, it will be a rather positive experience to confirm at start to
the user that the following list of extensions has been added, and that Firefox
will start using them from now one.

Also that's not strictly restricted to malware.
I have already seen people regret they have no control on Firefox making
automatically use of installed plugins, and that it's very hard to disable them.

There is an area where the software that installs the extension is not actually
evil, but still the user doesn't have enough control.

Comment 10

[Mike Connor [:mconnor]]

This is not a winnable fight.  Any sort of flag/trigger we can set up for first
install will just be bypassed if that's the malicious app's intent.  No matter
how many hoops we force users to jump through, a malicious app won't use a
legitimate process, and will probably bypass the entire chrome registration
process and just insert itself where it sees fit.  All we'll do here is pop up
extra dialogs for legitimate installs, giving users a false sense of security.

Comment 12

[JDev]

While the fight against malware may be unwinable, this would allow for protection against legitimate applications behaving improperly.  

Take Skype as an example, it auto installs its extension with good intension but without consulting the user.  FireFox 3's notification of install is good, but it should really be a choice if it is to be installed or not.  I would look at this as enhancing the user experience not detracting from it, especially since it is on load and only when a new extension appears without notice.

Comment 13

[JDev]

Further thoughts concerning user experience:

Consider the steps involved for the user when a third party user installs itself:

FF2)
1) Must monitor visible behaviour changes and/or the extension list to find out if something new was installed
2) uninsatll
3) restart firefox

FF3)
1) notice that new install is prompted vs just an upgrade to existing extension
2) go into addons menu, find, and uninstall
3) restart firefox

vs proposed alternative
1) click "install", "delete", or "decide later"

The install can behave as upgrades currently do so firefox isn't fully loaded before it installs and restarts.

This seems like a far more user friendly system.

Comment 14

[Dave Townsend [:mossop]]

I'm changing the resolution here. The basic intent here seems to be that a user should be warned if a third party application installs an extension. This is provided by bug 408115 so I'm resolving this as fixed.

While it is true that it would be possible for an extension to be installed in such a way as to bypass that there is nothing that we can ever do to avoid that situation that code running on the local machine would not be able to bypass.