User Agent: Mozilla/5.0 (X11; CrOS x86_64 13505.73.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.109 Safari/537.36

Steps to reproduce:

1. go to https://www.id.ee/en/article/install-id-software/
2. download and install software
3. close and restart chrome
4. See local install of a Firefox Policy with 1 extension (id: ckjefchnfjhjfedoccjbhjpbncimppeg) force installed

Actual results:

No installed profile in reference to terms of service for Firefox Management

Expected results:

The .exe and .dmg install a Firefox Profile on the platform level that force installs a Firefox extension. This is NOT a legitimate use of these profiles as it is outside of the distributing organisation.

Most people will not know how to just uninstall this profile and thus this is rightfully seen as malware. Please work with the distributor of the software (I have contacted them with this bug as well) to find alternative solutions and help normal users to either block or uninstall the profile.

Obviously I meant "restart firefox". I copied this from my report to the Chromium Team as they exhibit the same behaviour on multiple platforms.
Chrome Bug for reference: https://bugs.chromium.org/p/chromium/issues/detail?id=1161955 (security locked as well).

Mike/Andreas, can you take a look (when you're back)? AFAICT this is related to the Estonian ID card system, but from a brief glance I can't tell how the add-on is related and/or why they need to use enterprise policy to install it.

They are installing this extension:

https://addons.mozilla.org/en-US/firefox/addon/pkcs11-module-loader/

which installs the software security device that allows the Estonian ID to work

And they are using a normal policy install which means the user is free to uninstall it from the addons manager.

I'm not sure whether I agree or disagree with the mechanism, but the reality is that they ask for admin privileges and the user gives it, they are free to do anything to the system. There's not much we could do here.

I tend to disagree.

Issue one: Principle

A profile should only be used for internal management of company "owned" browsers and never for "normal" installation of an extension. Which also won't allow the user to uninstall the extension as they can only turn it off. This may be the same outcome but users don't care. Also, yes users clicked and allowed admin rights, but they do this for worse malware too...

Issue two: Multiple Profiles

I have no direct experience with managing Firefox but I do with Chrome.
I do not know if a device can have multiple profiles for Firefox and which would take precedence if there is only one possible. In Chrome I can have 3 layers of Management [1] (Device, Cloud, User). I primarily manage our devices via the Cloud Token [2]. As soon as this profile is being installed it will overwrite all of the other cloud and user management policies for extensions. I don't know how Firefox handles this but on the Chrome side this is rightfully seen as a malicious use of policies.

Issue three: Supply Chain Attack / future additional policies

Currently the .exe / .dmg's only install this one policy but that won't stop them or a potentially malicious attacker to install additional extensions or other potentially harmful additional policies.

I don't know what you can do to prevent them to do so other than reaching out yourself but I believe this is an issue that should be addressed. A policy just shouldn't be used in this way.

[1] https://chromeenterprise.google/browser/management/
[2] https://support.google.com/chrome/a/answer/9116814?hl=en

(In reply to Dominik Kugelmann from comment #5)

I tend to disagree.

Issue one: Principle

A profile should only be used for internal management of company "owned" browsers and never for "normal" installation of an extension.

I guess with our removing the ability to sideload add-ons, there might not be another way of doing this, other than asking users to do it (e.g. by opening a website with a big "click here to finish installation" button or whatever).

Which also won't allow the user to uninstall the extension as they can only turn it off.

I don't understand this. Did you test this on Firefox? Mike claims it is not true:

(In reply to Mike Kaply [:mkaply] from comment #4)

And they are using a normal policy install which means the user is free to uninstall it from the addons manager.

(needinfo for this)

(In reply to Dominik Kugelmann from comment #5)

users clicked and allowed admin rights, but they do this for worse malware too...

Sure, but there aren't that many ways application A can protect itself from application B that has admin rights.

Issue two: Multiple Profiles

I have no direct experience with managing Firefox but I do with Chrome.
I do not know if a device can have multiple profiles for Firefox and which would take precedence if there is only one possible. In Chrome I can have 3 layers of Management [1] (Device, Cloud, User). I primarily manage our devices via the Cloud Token [2]. As soon as this profile is being installed it will overwrite all of the other cloud and user management policies for extensions. I don't know how Firefox handles this but on the Chrome side this is rightfully seen as a malicious use of policies.

Firefox supports multiple local user profiles (try opening about:profiles). I defer to Mike but AIUI our enterprise policy support would affect all Firefox profiles on the machine, and there aren't any further layers to it. It sounds like the installer might overwrite other enterprise policy stuff already present on the local machine (but someone would need to test / inspect the installer to check). That seems problematic from a "actor A shouldn't overwrite stuff from actor B willy-nilly" perspective, but with admin rights on the machine and thus write access to the registry and the entire disk, I don't see how Firefox could protect the existing enterprise policy.

t is not in our gift to somehow prevent the installer from running, and blocking the add-on will not fix things, it'll just make the Estonian ID card system not work. It might feel like "punishing" the eID folks but mostly it'll be punishing the users and forcing them to switch browsers.

I'm also confused about the overwriting - on locked down machines with enterprise policy, I would not expect users to have admin rights (or they could already remove the enterprise policy if they wanted)... Can you elaborate on why users are allowed admin access to overwrite these cloud/user management policies in your situation? (needinfo for this too)

Issue three: Supply Chain Attack / future additional policies

Currently the .exe / .dmg's only install this one policy but that won't stop them or a potentially malicious attacker to install additional extensions or other potentially harmful additional policies.

This is a slippery slope argument. Chrome's installer could start uninstalling Firefox (or vice versa) automatically, but that doesn't mean we should stop users downloading the Chrome installer in our own browser... ;-)

I don't know what you can do to prevent them to do so other than reaching out yourself but I believe this is an issue that should be addressed.

Have you tried reaching out to the Estonian ID folks yourself? What do they think about this?

(In reply to Mike Kaply [:mkaply] from comment #4)

I'm not sure whether I agree or disagree with the mechanism, but the reality is that they ask for admin privileges and the user gives it, they are free to do anything to the system. There's not much we could do here.

I would tend to agree.

I was incorrect about normal_installed. Users can disable it, but they can't uninstall it.

Since this is about the way an add-on is installed and not the add-on content itself, I am not sure blocking is the right course of action. It would also not get us much, since the install process runs with admin rights anyway.

Mike or Gijs, what should happen to this bug? Could we either close it or move it to the right component? From what I understand, I don't see blocking the add-on as the best course of action.

I'm not sure there's anything we can do here. Shane, do we have other ways that we'd prefer they install this add-on?

I'm assuming the system level installer is installing necessary libraries/whatever for pkcs11 support, then installing a policy so firefox will pick up the addon. Anything else will only install for a single user (sideloading into profile or having the user install from a webpage).

I'm wondering though what the state of our internal pkcs11 support is, and whether allowing these addons is still necessary. Maybe Dana can give us some input.

FWIW this isn't really a security issue.

However, I do see potential in changing policies to require a pref flip in release versions of firefox (enabled on ESR), but I'd defer to Mike whether that is a good idea. What do you think Mike?

On Windows and macOS, osclientcerts is enabled by default in Nightly and Beta. It is available in release, but it is not enabled by default. I'm not aware of any outstanding issues with it at the moment, and every user I've mentioned it to has either said it works or has stopped responding in bugzilla. Also, it can be enabled via a policy, so I think it is generally what we want to be recommending for people to use, rather than 3rd-party modules. (The reason we haven't enabled it by default in release yet is to hopefully catch any issues the beta audience may encounter first.)
That said, it doesn't work for linux (or Android).

However, I do see potential in changing policies to require a pref flip in release versions of firefox (enabled on ESR), but I'd defer to Mike whether that is a good idea. What do you think Mike?

In order for policies to be effective, they have to work by default in all versions of Firefox. Otherwise someone could just install a version of Firefox that doesn't have policies to avoid any policy configuration.

This doesn't need to remain hidden IMHO. It's a disagreement about design that could use broader discussion. The add-on in question might be doing something the reporter doesn't like, but it's not "malicious". Whether we should limit the ability (providing alternatives) so outright malicious folks don't take advantage is a good thing to discuss, but people obviously already know about this mechanism because they're using it openly.

Any disagreement before I do so?

(In reply to Daniel Veditz [:dveditz] from comment #15)

Any disagreement before I do so?

no, it can be public

I wonder if we shouldn't consider some UI regarding policies. If an existing profile suddenly gains a policy file, should we notify the user? maybe point them to about:policies and some helpful documentation

(In reply to Shane Caraveo (:mixedpuppy) from comment #17)

I wonder if we shouldn't consider some UI regarding policies. If an existing profile suddenly gains a policy file, should we notify the user? maybe point them to about:policies and some helpful documentation

--> mkaply

(also unhiding given we seem to all agree on that)

I wonder if we shouldn't consider some UI regarding policies. If an existing profile suddenly gains a policy file, should we notify the user? maybe point them to about:policies and some helpful documentation.

We have that in preferences at the top. Edge and Chrome have it in their hamburger menu as well (and it shows up there for this case for both of them).

I had to explicitly remove the registry for Edge so I could use some features again.

I'd be interested to know if they are going to do anything, but we can't see their bugs.

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.