Closed Bug 1651405 Opened 9 months ago Closed 8 months ago

Setting "privacy.resistFingerprinting.block_mozAddonManager" to True causes installing extensions from AMO to fail

Categories

(Toolkit :: Add-ons Manager, defect)

79 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 1308251

People

(Reporter: thatch, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0

Steps to reproduce:

  1. Set "privacy.resistFingerprinting.block_mozAddonManager" to True.
  2. Restart Firefox.
  3. Try to install an extention from AMO.

Actual results:

When you try to install an extension from AMO, it will fail with the error "addons.mozilla.org - The add-on could not be downloaded because of a connection failure."

Expected results:

It should have installed properly.

If you switch "privacy.resistFingerprinting.block_mozAddonManager" to False, extensions install properly. (Don't recall if you need to restart browser to reflect this)

See Also: → 1384330

If you set browser.tabs.remote.separatePrivilegedMozillaWebContentProcess to false, does it succeed?

Flags: needinfo?(thatch)

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Add-ons Manager
Product: Firefox → Toolkit

(In reply to Tom Ritter [:tjr] (ni for response to sec-[approval|rating|advisories|cve]) from comment #1)

If you set browser.tabs.remote.separatePrivilegedMozillaWebContentProcess to false, does it succeed?

No. Setting that to False has no effect on this bug.

Flags: needinfo?(thatch)

(In reply to Tandy from comment #3)

Tandy, are you blocking "cookies" - either by setting block all cookies in preferences, or with an extension? The cookies setting control cookies, localStorage, IDB etc, and when that happens, addons.xpi will log a message that the sha1 hash failed (because I assume it can't read the value back).

This is the only way I can replicate this. The pref (and others such as extensions.webextensions.restrictedDomains, permissions.manager.defaultsUrl, webchannel.allowObject.urlWhitelist and the one Tom mentioned) do not block addon installs from AMO

(In reply to Simon Mainey from comment #4)

Simon, there is no cookie blocking either through preferences or extensions.

This is a brand new instance of FF Dev Edition v79 b4 - so all preferences, and about:config settings are at defaults with zero extensions installed.

I can take that clean Firefox app and install a sample extension from AMO, which works just fine. Then I will add "privacy.resistFingerprinting.block_mozAddonManager" as a Boolean set to True, restart the browser, and when I try to install an extension again - I get the error listed in the OP.

Note that after creating/setting "privacy.resistFingerprinting.block_mozAddonManager" to True, you have to restart the browser for the bug to show up. If you try to install an extension in the same session - it will work and the bug won't be visible.

Thanks Tandy. Yes, I was restarting when flipping the pref. The thing is I have this same issue in my main Firefox and have for at least 4 releases (hard to tell because I very rarely install new extensions), so I thought I would track down the culprit since you opened a ticket. I have an extensive Firefox test suite here, and I cannot replicate in Nightly, Dev, Beta, FF78: all vanilla profiles. So IDK, for me it was because I block cookies by default.

Do you get anything in the console? Like a log entry similar to this

1594254524332	addons.xpi	WARN	Download of https://addons.cdn.mozilla.net/user-media/addons/229918/https_everywhere-2020.5.20-an+fx.xpi?filehash=sha256%3Aec94fcb5d481d3bf09e4519f8b06a232ac7a4fbdf78ee38c92ae659e668d9283 failed: 2147500036

(In reply to Simon Mainey from comment #6)

When this bug is active (i.e. privacy.resistFingerprinting.block_mozAddonManager = True ), and I try to install an extension from AMO, the console shows this error:

20:51:35.054 1594266695053	addons.xpi	WARN	Download of https://addons.cdn.mozilla.net/user-media/addons/745973/scrollanywhere-8.4-an+fx.xpi?filehash=sha256%3A185062b2d041bcdb28f3fc8630a9a3e1d6f550268e221f7d4f55352d8b3a202e failed: [Exception... "Certificate issuer is not built-in."  
nsresult: "0x80004004 (NS_ERROR_ABORT)"  location: "JS frame :: resource://gre/modules/CertUtils.jsm :: checkCert :: line 183"  data: no] Stack trace: checkCert()@resource://gre/modules/CertUtils.jsm:183
onStopRequest()@resource://gre/modules/addons/XPIInstall.jsm:2404

Hello,

Following the provided STR, I did not manage to reproduce the issue on the latest Nightly (80.0a1/20200710033027), Beta (79.0b6/20200709230528), Release (78.0.2/20200708170202), Beta Dev Edition 79.0b4 (79.0b4/20200703150958) nor the latest Beta Dev Edition 79.0b6 (79.0b6/20200709230528). Tested on Windows 10 Pro 64-bit and Ubuntu 16.04 LTS.

After setting the mentioned pref to true and restarting the browser, I’m able to install add-ons from AMO without any issues whatsoever.

resource://gre/modules/CertUtils.jsm:183

  if (!issuerCert.isBuiltInRoot) {
    throw new Ce(certNotBuiltInErr, Cr.NS_ERROR_ABORT);
  }

(In reply to Alex Cornestean from comment #8)

Hello,

Following the provided STR, I did not manage to reproduce the issue on the latest Nightly (80.0a1/20200710033027), Beta (79.0b6/20200709230528), Release (78.0.2/20200708170202), Beta Dev Edition 79.0b4 (79.0b4/20200703150958) nor the latest Beta Dev Edition 79.0b6 (79.0b6/20200709230528). Tested on Windows 10 Pro 64-bit and Ubuntu 16.04 LTS.

After setting the mentioned pref to true and restarting the browser, I’m able to install add-ons from AMO without any issues whatsoever.

I also tried in 79 and 80 and couldn't reproduce....

Maybe a video of starting from a fresh profile would help us duplicate your steps?

The severity field is not set for this bug.
:mixedpuppy, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(mixedpuppy)

(In reply to Tandy from comment #7)

20:51:35.054 1594266695053	addons.xpi	WARN	Download of https://addons.cdn.mozilla.net/user-media/addons/745973/scrollanywhere-8.4-an+fx.xpi?filehash=sha256%3A185062b2d041bcdb28f3fc8630a9a3e1d6f550268e221f7d4f55352d8b3a202e failed: [Exception... "Certificate issuer is not built-in."  
nsresult: "0x80004004 (NS_ERROR_ABORT)"  location: "JS frame :: resource://gre/modules/CertUtils.jsm :: checkCert :: line 183"  data: no] Stack trace: checkCert()@resource://gre/modules/CertUtils.jsm:183
onStopRequest()@resource://gre/modules/addons/XPIInstall.jsm:2404

This looks like you have a MitM certificate installed, perhaps as part of your corporate network? Are you able to try this from another network/location?

Also, we had changes recently to drop this (or related) checks, so you might wanna try with a newer build of Nightly.

Flags: needinfo?(mixedpuppy) → needinfo?(thatch)
Flags: needinfo?(mixedpuppy)

Changing the value of block_mozAddonManager does not require a restart to take effect. You can verify that by installing any addon from AMO. On AMO (on the page for the given addon) you'll see the button for the addon shows "uninstall" for installed addons (or "enable" if they are installed and disabled). If you flip the pref to true, and simply reload that page, the button will change to "install" because the api is no longer available. Install continues to work, you just don't have the closer integration with AMO.

I agree that the problem here is actually the builtincert issue, and that has been addressed in bug 1308251.

Status: UNCONFIRMED → RESOLVED
Closed: 8 months ago
Flags: needinfo?(mixedpuppy)
Resolution: --- → DUPLICATE
Duplicate of bug: CVE-2020-12421
You need to log in before you can comment on or make changes to this bug.