396510 - Remove EM command line global installation capability (e.g. -install-global-extension and -install-global-theme)

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

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

These were added for Firefox 1.0 since there was no way to install extensions to the application's extensions directory. Removing this capability removes an attack vector that has been used in several proof of concepts as of late and I believe it can now be removed since it is possible to install add-ons by placing the extracted add-on into a directory named with the add-on's id into the application's extensions directory or the xpi into the application's directory if the user that launches next has write access.

The main thing blocking this IMO is that the doc's should be updated to provide better information on how to deploy add-ons using the place the add-on directory method.

Comment 1

[Dave Townsend [:mossop]]

I was going to suggest this at some point my self. Administrators can install system wide addons without having to even run firefox.

Comment 2

[Mike Kaply [:mkaply]]

Well it is a little painful for administrators. You have to unzip the XPI, Read the install.rdf to get the ID, then create the directory and unzip into it.

The problem is that the directory name is the ID which is bundled up in the XPI.

Maybe we can provide some external utility to do this?

Comment 3

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

I think a utility would be appropriate... it should be simple enough to accomplish with an extension using a toolkit id with ui made available via its options.

Comment 4

[Jesse Ruderman]

Even if these are removed, attackers will still be able to use -P, so we should probably also do the "register something other than firefox.exe as the default browser" thing.  Is there a bug on that?

Comment 5

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

That's Bug 396196

Comment 6

[Dave Townsend [:mossop]]

I think we should probably be deprecating the install to application directory. We have other OS-wide install locations on all platforms now, whatever utility we create to replace these command line arguments can install there. This will be safer in the long run, we already have had to make the installer automatically remove certain extensions in the app dir if they exist.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #6)
> We have other OS-wide install locations on all platforms now, whatever utility

Do you have a bug # off-hand where the implementation was done? Or where can be found some more information about?

Comment 8

[Dave Townsend [:mossop]]

(In reply to comment #7)
> Do you have a bug # off-hand where the implementation was done? Or where can be
> found some more information about?

Windows has had them for pretty much ever, others were done in bug 311008 and related

Comment 9

[Mike Kaply [:mkaply]]

Just to be clear, extensions will still be allowed in the global extensions directory, there will just be no Firefox mechanism to put them there automatically.

Comment 10

[Dave Townsend [:mossop]]

Yes, that is required to stay anyway so that extensions can be shipped with the application

Comment 11

[Dave Townsend [:mossop]]

Attachment: patch rev 1

This drops the command line options. I've also dropped the commandLine argument from the EM's start method. It isn't used and I can't think of a reason why we might ever need it.

I don't think we need tests for this as it is basically code removal. So long as all current tests pass we should be good. The code in question was untested anyway.

Comment 12

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

Comment on attachment 376398 [details] [diff] [review]
patch rev 1

>diff --git a/toolkit/mozapps/extensions/public/nsIExtensionManager.idl b/toolkit/mozapps/extensions/public/nsIExtensionManager.idl
>--- a/toolkit/mozapps/extensions/public/nsIExtensionManager.idl
>+++ b/toolkit/mozapps/extensions/public/nsIExtensionManager.idl
You should be able to also remove interface nsICommandLine;

With that r=me

Comment 13

[Dave Townsend [:mossop]]

Landed: http://hg.mozilla.org/mozilla-central/rev/c61c8e18dba6

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verified fixed with:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090513 Minefield/3.6a1pre ID:20090513034237

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090513 Minefield/3.6a1pre ID:20090513044918

Comment 15

[Dimas]

I'm an admin of a 500+ computers company with Firefox on all of them. I need all users have some corporate extensions installed by default, and until FF 3.6 I can do it with batch scripts, netlogon and -install-global-extension command.

Ok, now you have decided to disallow that command, so I've updated the script to copy the xpi to the app 'extensions' directory. But I don't want that every time I update the extensions or install new ones the users can choose to install or not these. Is there an option (user_pref) to disable that alert?

I hope that... if not, I've to stay with FF 3.5 or maybe try another browser.

Comment 16

[Dave Townsend [:mossop]]

(In reply to comment #15)
> Ok, now you have decided to disallow that command, so I've updated the script
> to copy the xpi to the app 'extensions' directory. But I don't want that every
> time I update the extensions or install new ones the users can choose to
> install or not these. Is there an option (user_pref) to disable that alert?

You should be extracting the xpi to the appropriately named folder in the extensions folder, not just copying it there. Ask in the appropriate newsgroups or support forums if you cannot get that to work.

Comment 17

[Stephen Thomas]

I just wrote a little script that does exactly that, but it doesn't achieve much. The unpacked xpi's all show up correctly in Tools->Addons, but none of them actually *do* anything.

There is a definite need for an easily scripted administrative method for performing a silent system-wide extension install that an end user can't possibly break by clicking the wrong button. The -install-global-extension parameter used to do exactly that, and I'm sure I won't be the last netadmin to find my way into this bug report after spending many fruitless hours trying to work around its removal.

To reduce future noise here, could a developer perhaps post a link to a clear description of the mechanism we are supposed to use instead?

Comment 18

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

One easy surefire way to do this is to install the extension normally, then take the directory for the newly installed extension in the profile inside the extensions directory, and then copy it to the installation directory's extensions directory. The first two steps only need to be done once per extension.

Comment 19

[Stephen Thomas]

From a netadmin point of view, that looks like a time-wasting manual repackaging chore. What did -install-global-extension used to put in an installed extension's directory other than the unzipped contents of the xpi, and is there a straightforward way to generate that extra stuff from the xpi alone?

Comment 20

[Dave Townsend [:mossop]]

(In reply to comment #19)
> From a netadmin point of view, that looks like a time-wasting manual
> repackaging chore. What did -install-global-extension used to put in an
> installed extension's directory other than the unzipped contents of the xpi,
> and is there a straightforward way to generate that extra stuff from the xpi
> alone?

Nothing extra was ever put into the directory. Rob's suggestion just makes sure you get the directory name right etc.

Comment 21

[Stephen Thomas]

For what it's worth, my little script got its directory names from the first <em:id> line inside the xpi's own install.rdf; the names it picked matched those used by -install-global-extension on another computer for the same set of xpi files. I believe I have the directory names right.

I'd like to know what else I should check (what is "etc."?) but this is surely the wrong place for debugging my own code, so I've opened a forum thread:

http://forums.mozillazine.org/viewtopic.php?f=7&t=1724155

Comment 22

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

You can try the method I suggested and compare it against the end result of your script to get an idea as to what is different / why it isn't working.

Comment 23

[Stephen Thomas]

Fixed now. Sorry about the derail.

http://forums.mozillazine.org/viewtopic.php?p=8579915#p8579915

Comment 24

[Stephen Thomas]

The current release notes explain a procedure for moving an extension from locally installed to global:

http://www.mozilla.com/en-US/firefox/3.6/releasenotes/#troubleshooting

Is that whole paragraph now obsolete, or only the part that mentions -install-global-extension?