429319 - Disable insecure extension installations by default

Status: RESOLVED WORKSFORME

(Toolkit :: Add-ons Manager, enhancement)

Description

[Eric Jung [:ericjung]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13

To logically extend bug 378216, we should prevent insecure extension installations by default. Perhaps this means addons should only be installed over SSL and/or using InstallTrigger. Maybe there are other possibilities.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Dave Townsend [:mossop]]

Valid request though needs thought over just what is "insecure". Bug 378216 was mostly about ensuring that the update you got came from the same author as the version you already had installed.

I guess the mirror for the install case is to ensure that the xpi you get comes from the same person as wrote the webpage? Which yes could be ensured by requiring ssl or an InstallTrigger with hash.

Comment 2

[Jesse Ruderman]

It would be strange to put this restriction on extension installation but not on executable download.  But it's even more strange that we scream at banks to prevent MITM attacks but not at software vendors, and maybe extensions are a good place to start.

See also:
* Bug 310355, Better indicators of how secure the xpi install is
* Bug 249951, Safer handling of executable files with download manager
* Bug 358384, Force https for www.mozilla.com and Firefox downloads
* Bug 292481, Support link fingerprints for downloads

Comment 3

[Volker Kleinschmidt]

As I commented over in bug 378216:
"Hmm, a setting that forces me to forego use of an extension entirely just
because it doesn't have a secure update method registered is the first thing
that will have to be disabled, and stay so. If you wanted to make things secure
you would prevent auto-update of such extensions, not their installation."

The point I'm trying to make is that I and many other end users rely on a lot of extensions, and their availability is key to our use of the Firefox browser - it is precisely the existence of so many extensions that makes people choose Firefox and stick with it as other interesting browser choices such as Chrome become available.
So when a Firefox update comes along that breaks some of those key extensions, I do not install it - I cannot afford to. And if there is a setting that allows me to work with those extensions on the upgraded Fx, then that's the setting I will set.
When trying to enhance security, the foremost concern has to be with usability - if you lock the door on someone's house for security reasons, he will climb out the window, because he has to get out.
There is no enhancement to security achieved when the code change forces people to turn it off. This new installation prevention for extensions without a secure update mechanism is a perfect example of that. If you want people to have the benefit of the security enhancement, you would still let them install the extension, but check at update time whether the updater is secure, and only let secure updaters run.

The installation prevention is a pitchfork approach. We need something much more precise.

Comment 4

[Dave Townsend [:mossop]]

Sorry Volker, but this bug had nothing to do with disabling the install of extensions that do not have secure update mechanisms. A couple of your raised concerns are maybe relevant but in any case when trying to enhance security, the foremost concern has to be with security, not with usability. Usability comes a strong second though. Both here and with the secure update case we can enhance the security without impacting the user's experience, providing that the add-on developer updates their extension properly. If they aren't then I'd wonder whether it was safe to continue to use that add-on anyway.

Comment 5

[Volker Kleinschmidt]

Yes, it has something to do with it, in that it's the same concept of locking the door first to protect the poor miser inside, and worrying second about how he might get out. You're not the police. When someone submits a form with an insecure URL, the browser pops up a warning, but lets the user choose to submit. Your approach would simply prevent the submission.

If I install an add-on, I don't know whether it will break my system, even if it was delivered securely from the add-on's author. And I want to be able to use legacy extensions that I need for my daily work. Yes, there is a certain risk involved. I'll make that call, thank you.

Comment 6

[Dave Townsend [:mossop]]

(In reply to comment #5)
> When someone submits a form with an
> insecure URL, the browser pops up a warning, but lets the user choose to
> submit. Your approach would simply prevent the submission.

These are vastly different risks though. In one case you are submitting a small amount of known data to a website. It is possible for you to be able to determine whether you are ok with that data being eavesdropped on. In the case of extension installation though you are talking about letting a rogue extension that you cannot see or evaluate install on the system where it then has access to all your personal data to send it anywhere on the web or delete it as it wishes.
 
> If I install an add-on, I don't know whether it will break my system, even if
> it was delivered securely from the add-on's author. And I want to be able to
> use legacy extensions that I need for my daily work. Yes, there is a certain
> risk involved. I'll make that call, thank you.

Legacy add-ons are really not the concern here, nor are any add-ons you are likely to try to install. The risk is that it is possible for a malware extension to be installed when you expect to get something else. There would also be nothing stopping you making that call. Just as there are ways around the secure update requirements, there would be ways around this if it was implemented. It would just require additional steps on your part, this is about trying to allow users to enjoy a safe experience on the web while you are free to leave yourself open to attack if you like.

Comment 7

[Andy McKay]

With WebExtensions add-ons are all signed by a Mozilla certificate, updates must be over https, have a limited sandbox and prompt a user for explicit permissions beforehand. If the reporter would like to suggest more in the new world, then maybe a new bug would be appropriate, but the add-ons ecosystem has changed significantly since this was created.