frederik Reporter
	Description • 7 years ago

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36

Steps to reproduce:

In firefox 58 in Windows 10, I installed the eid webextention from https://addons.mozilla.org/en-US/firefox/addon/belgium-eid/
This webextention reads out setting from the windows registry to find a json file that tells it where to find a pkcs library to load into firefox. (From what I've been told the pkcs11 library is not running in a container, but into the Firefox process itself).
This json file and registry settings were placed there by a signed NSIS installer that needed administrator permissions. installer can be found here: https://eid.belgium.be/en

The user on my OS does not have admin permissions so cannot override the above config files.



Actual results:

When creating similar config files (by the non-admin user, or an installer that does not need admin permissions) in the windows registry under HKCU and have it pointed towards a json file in a folder that is writable by the user, firefox will load the pkcs11 library mentioned in this new json file.

So once a user has installed the eid webextention, firefox will load in about any library a non-related third party installer without admin permissions installs


Expected results:

Preferably the eID Webextention already knows where to look for the matching pkcs11 module (in the system directory), without going through configuration data that can be changed by third parties.
Or at least ignore pkcs11 config information from the HKCU registry

	:Gijs (he/him)
	Comment 1 • 7 years ago

Andy, can you look at this and move this bug as appropriate / figure out next steps? AFAICT the registry stuff is in our implementation of the pkcs11 stuff, so it's up to Firefox to do something else here, if that's necessary/appropriate.

	Tomislav Jovanovic :zombie
	Comment 2 • 7 years ago

I don't think this is a security issue, this is working as intended: as discussed, designed and implemented in bug 1357391.

There is no new attack vector in what you are describing, any user-level installer has access to user's profile, and can configure it however it wishes, including adding PKCS#11 modules, and probably even worse things.

Please give more details if you can show a new way to harm users, otherwise I suggest closing this.

	frederik Reporter
	Comment 3 • 7 years ago

Well, the old eid extention on windows was looking for a pkcs11 module in the windows system directory, where it only could have been placed by someone with admin rights.
The new extention can be fooled into loading a different pkcs11 module by someone with user rights, so there is a permission level drop (to place a fake pkcs11 module) vs. the old situation.

	:Gijs (he/him)
	Comment 4 • 7 years ago

(In reply to frederik from comment #3)
> Well, the old eid extention on windows was looking for a pkcs11 module in
> the windows system directory, where it only could have been placed by
> someone with admin rights.
> The new extention can be fooled into loading a different pkcs11 module by
> someone with user rights, so there is a permission level drop (to place a
> fake pkcs11 module) vs. the old situation.

But if the attacker has access to the profile dir, in the old situation they could have just placed an additional pkcs11 module there themselves, and, if they wanted to, uninstalled the official extension, right?

If we treat this as an attack against the add-on, then I guess the only real way to fix it is to ensure the add-on can (delegate to Firefox the ability to) verify that it's loading the expected module by means of a checksum or similar. That would need API additions on the Firefox side.

	Tomislav Jovanovic :zombie
	Comment 5 • 7 years ago

Either that, or a policy change that admin-level config trumps user-level.  But that sounds like an enterprise policy feature, and not a security bug.

(In reply to Tomislav Jovanovic :zombie from comment #2)
> otherwise I suggest closing this.

I think we can just drop the security flag for now instead.

(and discuss this with some of the Enterprise folks, like mkaply)

	Kris Maglione [:kmag]
	Comment 6 • 7 years ago

Agreed, this is the expected behavior, and doesn't present a security risk, given that ordinary write access to the profile directory already allows attackers to do much more interesting things without requiring a PKCS#11 extension to be installed.

We should open this bug, but I unfortunately can't, since I'm not in the Firefox security group.