Bug 1908018 - Firefox add-on installation uses sha1 signatures which are no longer approved by policy
Summary: Firefox add-on installation uses sha1 signatures which are no longer approved...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: rawhide
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Martin Stransky
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: openqa
: 1907731 1912234 (view as bug list)
Depends On:
Blocks: F34BetaBlocker 1909386
TreeView+ depends on / blocked
 
Reported: 2020-12-15 17:20 UTC by Adam Williamson
Modified: 2021-10-26 10:51 UTC (History)
28 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-01-13 17:19:14 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Mozilla Foundation 1682613 0 P3 NEW Move Add-ons to SHA-256 Signatures and disable SHA-1 Signatures for Add-ons 2021-02-18 15:14:23 UTC

Description Adam Williamson 2020-12-15 17:20:16 UTC
With nss-3.59.0-2.fc34 , installing add-ons in Firefox is broken. This broke between 3.58.0-8.fc34 and 3.59.0-2.fc34; not sure if 3.59.0-1.fc34 had the bug.

When trying to install an add-on you get an error "Installation aborted because the add-on appears to be corrupt." This is not a problem with the add-on, it works fine with 3.58.0. mstransky confirmed this bug on the F33 update ticket - https://bodhi.fedoraproject.org/updates/FEDORA-2020-44d771d0ef#comment-1776319 . openQA is hitting it in tests of the F33 update and also of Rawhide.

Proposing as a Beta blocker per Basic criterion "It must be possible to run the default web browser and a terminal application from all release-blocking desktop environments...The web browser must be able to download files, load extensions (if applicable)..." - https://fedoraproject.org/wiki/Basic_Release_Criteria#Required_applications

Comment 1 Kevin Fenzi 2020-12-15 18:06:49 UTC
*** Bug 1907731 has been marked as a duplicate of this bug. ***

Comment 2 Martin Stransky 2020-12-16 10:34:39 UTC
More info is at https://bodhi.fedoraproject.org/updates/FEDORA-2020-44d771d0ef

Comment 3 Martin Stransky 2020-12-16 10:36:38 UTC
As a temporary workaround I'm going to ship Firefox with in-tree nss until this one is solved.

Comment 4 Martin Stransky 2020-12-16 10:45:11 UTC
Comments from rrelyea:

OK, the issue is add-ons appear to be using sha1 signatures, which are not disabled by policy. NSS 3.59 is now enforcing general signatures. If you use update-crypto-policies -set LEGACY add-ons work will work.

The question is how we should deal with this. We shouldn't back out the enforcement in NSS. I'm not sure if we should hack around it in Firefox until add-ons update, or if we should just require LEGACY crypto policies if you want to load add-ons. Does anyone know if firefox is moving to using SHA-2 for add-ons anytime soon?

To turn SHA1 on for non-certificate signatures: / Sets the NSS_USE_ALG_IN_ANY_SIGNATURE bit. does not change NSS_USE_ALG_IN_CERT_SIGNATURE / rv = NSS_SetAlgorithmPolicy(SEC_OID_SHA1, NSS_USE_ALG_IN_ANY_SIGNATURE, 0); / checking rv is optional here, more likely to give a nice error message if policy is * locked /

To temporarily turn policy on for one function: / Get the previous state of the signature policy bit / policy=0; policy_rv = NSS_GetAlgorithmPolicy(SEC_OID_SHA1, &policy); if (policy_rv == SECSuccess) { / this sets policy to NSS_USE_ALG_IN_ANY_SIGNATURE if that bit was off, We'll use it to clear * that bit after we complete our command / policy = (~policy & NSS_USE_ALG_IN_ANY_SIGNATURE) ; / turn on policy / policy_rv = NSS_SetAlgorithmPolicy(SEC_OID_SHA1, NSS_USE_ALG_IN_ANY_SIGNATURE, 0); } / do function here / if (policy_rv == SECSuccess) { / clear the policy bit again if it was off before / NSS_SetAlgorithmPolicy(SEC_OID_SHA1, 0, policy); }

Probably the easiest is have a pref that enables sha1 signatures for add-ons and is it's set just flip the policy bit and not worry about saving and clearing it, since it only affects policy for firefox.

Comment 5 Kevin Fenzi 2020-12-16 19:53:24 UTC
I see you pushed updates reverting this for stable releases. Could you also do so for rawhide? Or is there some reason there's not a rawhide build yet?

Comment 6 Martin Stransky 2020-12-16 20:19:57 UTC
(In reply to Kevin Fenzi from comment #5)
> I see you pushed updates reverting this for stable releases. Could you also
> do so for rawhide? Or is there some reason there's not a rawhide build yet?

If you mean Firefox the builds with in-tree nss are here (firefox-84.0-4.*):
https://koji.fedoraproject.org/koji/packageinfo?packageID=37

Comment 7 Martin Stransky 2020-12-16 20:22:13 UTC
Ah, I see new nss builds with SHA-1 changes are 3.59.0-3. Will rebuild Firefox for it.

Comment 8 Bob Relyea 2020-12-16 22:03:42 UTC
Because we need the general NSS functionality (ability to turn off all signatures based on policy) in rawhide, so we need to deal with it separately going forward (either upstream or a ff patch). Since f32 and f33 are already released, they don't need that functionality so it's OK to disable it.

Comment 9 Bob Relyea 2020-12-16 22:10:29 UTC
Mozilla upstream bug for this: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1682613

Comment 10 Kevin Fenzi 2020-12-16 22:32:21 UTC
(In reply to Bob Relyea from comment #8)
> Because we need the general NSS functionality (ability to turn off all
> signatures based on policy) in rawhide, so we need to deal with it
> separately going forward (either upstream or a ff patch). Since f32 and f33
> are already released, they don't need that functionality so it's OK to
> disable it.

Sure, but we should disable it _for now_ in rawhide until we have a plan.
 
Or is the plan to have firefox not use system nss in rawhide? (That seems more divergent than just patching nss in rawhide like the release branches, but ok if thats the plan).

Comment 11 Martin Stransky 2020-12-17 06:20:26 UTC
(In reply to Kevin Fenzi from comment #10)
> Sure, but we should disable it _for now_ in rawhide until we have a plan.
>  
> Or is the plan to have firefox not use system nss in rawhide? (That seems
> more divergent than just patching nss in rawhide like the release branches,
> but ok if thats the plan).

Yes, as a hotfix Firefox without system nss will be available there.
It should be already but the build failed on x86_64:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1659542

Comment 12 Vít Ondruch 2020-12-17 15:52:50 UTC
I don't think that FF should ever provide libnss:

~~~
$ rpm -qPp https://kojipkgs.fedoraproject.org//packages/firefox/83.0/14.fc34/x86_64/firefox-83.0-14.fc34.x86_64.rpm
application()
application(firefox.desktop)
firefox = 83.0-14.fc34
firefox(x86-64) = 83.0-14.fc34
libclearkey.so()(64bit)
liblgpllibs.so()(64bit)
libmozavcodec.so()(64bit)
libmozavcodec.so(libmozavcodec.so)(64bit)
libmozavutil.so()(64bit)
libmozavutil.so(libmozavutil.so)(64bit)
libmozgtk.so()(64bit)
libmozsandbox.so()(64bit)
libmozsqlite3.so()(64bit)
libmozsqlite3.so(libmozsqlite3.so)(64bit)
libmozwayland.so()(64bit)
libxul.so()(64bit)
libxul.so(xul83)(64bit)
metainfo()
metainfo(firefox.appdata.xml)
mimehandler(application/vnd.mozilla.xul+xml)
mimehandler(application/xhtml+xml)
mimehandler(text/html)
mimehandler(text/mml)
mimehandler(text/xml)
mimehandler(x-scheme-handler/http)
mimehandler(x-scheme-handler/https)
webclient

$ rpm -qPp https://kojipkgs.fedoraproject.org//packages/firefox/84.0/6.fc34/x86_64/firefox-84.0-6.fc34.x86_64.rpm
application()
application(firefox.desktop)
firefox = 84.0-6.fc34
firefox(x86-64) = 84.0-6.fc34
libclearkey.so()(64bit)
libfreeblpriv3.so()(64bit)
libfreeblpriv3.so(NSSprivate_3.11)(64bit)
libfreeblpriv3.so(NSSprivate_3.16)(64bit)
liblgpllibs.so()(64bit)
libmozavcodec.so()(64bit)
libmozavcodec.so(libmozavcodec.so)(64bit)
libmozavutil.so()(64bit)
libmozavutil.so(libmozavutil.so)(64bit)
libmozgtk.so()(64bit)
libmozsandbox.so()(64bit)
libmozsqlite3.so()(64bit)
libmozsqlite3.so(libmozsqlite3.so)(64bit)
libmozwayland.so()(64bit)
libnspr4.so()(64bit)
libnss3.so()(64bit)
libnss3.so(NSS_3.10)(64bit)
libnss3.so(NSS_3.10.2)(64bit)
libnss3.so(NSS_3.11)(64bit)
libnss3.so(NSS_3.11.1)(64bit)
libnss3.so(NSS_3.11.2)(64bit)
libnss3.so(NSS_3.11.7)(64bit)
libnss3.so(NSS_3.11.9)(64bit)
libnss3.so(NSS_3.12)(64bit)
libnss3.so(NSS_3.12.1)(64bit)
libnss3.so(NSS_3.12.10)(64bit)
libnss3.so(NSS_3.12.3)(64bit)
libnss3.so(NSS_3.12.4)(64bit)
libnss3.so(NSS_3.12.5)(64bit)
libnss3.so(NSS_3.12.6)(64bit)
libnss3.so(NSS_3.12.7)(64bit)
libnss3.so(NSS_3.12.9)(64bit)
libnss3.so(NSS_3.13)(64bit)
libnss3.so(NSS_3.13.2)(64bit)
libnss3.so(NSS_3.14)(64bit)
libnss3.so(NSS_3.14.1)(64bit)
libnss3.so(NSS_3.14.3)(64bit)
libnss3.so(NSS_3.15)(64bit)
libnss3.so(NSS_3.15.4)(64bit)
libnss3.so(NSS_3.16.1)(64bit)
libnss3.so(NSS_3.16.2)(64bit)
libnss3.so(NSS_3.18)(64bit)
libnss3.so(NSS_3.19)(64bit)
libnss3.so(NSS_3.19.1)(64bit)
libnss3.so(NSS_3.2)(64bit)
libnss3.so(NSS_3.2.1)(64bit)
libnss3.so(NSS_3.21)(64bit)
libnss3.so(NSS_3.22)(64bit)
libnss3.so(NSS_3.3)(64bit)
libnss3.so(NSS_3.3.1)(64bit)
libnss3.so(NSS_3.30)(64bit)
libnss3.so(NSS_3.31)(64bit)
libnss3.so(NSS_3.33)(64bit)
libnss3.so(NSS_3.34)(64bit)
libnss3.so(NSS_3.39)(64bit)
libnss3.so(NSS_3.4)(64bit)
libnss3.so(NSS_3.43)(64bit)
libnss3.so(NSS_3.44)(64bit)
libnss3.so(NSS_3.45)(64bit)
libnss3.so(NSS_3.47)(64bit)
libnss3.so(NSS_3.5)(64bit)
libnss3.so(NSS_3.52)(64bit)
libnss3.so(NSS_3.53)(64bit)
libnss3.so(NSS_3.55)(64bit)
libnss3.so(NSS_3.58)(64bit)
libnss3.so(NSS_3.59)(64bit)
libnss3.so(NSS_3.6)(64bit)
libnss3.so(NSS_3.7)(64bit)
libnss3.so(NSS_3.7.1)(64bit)
libnss3.so(NSS_3.8)(64bit)
libnss3.so(NSS_3.9)(64bit)
libnss3.so(NSS_3.9.2)(64bit)
libnss3.so(NSS_3.9.3)(64bit)
libnssutil3.so()(64bit)
libnssutil3.so(NSSUTIL_3.12)(64bit)
libnssutil3.so(NSSUTIL_3.12.3)(64bit)
libnssutil3.so(NSSUTIL_3.12.5)(64bit)
libnssutil3.so(NSSUTIL_3.12.7)(64bit)
libnssutil3.so(NSSUTIL_3.13)(64bit)
libnssutil3.so(NSSUTIL_3.14)(64bit)
libnssutil3.so(NSSUTIL_3.15)(64bit)
libnssutil3.so(NSSUTIL_3.17.1)(64bit)
libnssutil3.so(NSSUTIL_3.21)(64bit)
libnssutil3.so(NSSUTIL_3.24)(64bit)
libnssutil3.so(NSSUTIL_3.25)(64bit)
libnssutil3.so(NSSUTIL_3.31)(64bit)
libnssutil3.so(NSSUTIL_3.33)(64bit)
libnssutil3.so(NSSUTIL_3.38)(64bit)
libnssutil3.so(NSSUTIL_3.39)(64bit)
libnssutil3.so(NSSUTIL_3.59)(64bit)
libplc4.so()(64bit)
libplds4.so()(64bit)
libsmime3.so()(64bit)
libsmime3.so(NSS_3.10)(64bit)
libsmime3.so(NSS_3.12.10)(64bit)
libsmime3.so(NSS_3.12.2)(64bit)
libsmime3.so(NSS_3.13)(64bit)
libsmime3.so(NSS_3.15)(64bit)
libsmime3.so(NSS_3.16)(64bit)
libsmime3.so(NSS_3.18)(64bit)
libsmime3.so(NSS_3.2)(64bit)
libsmime3.so(NSS_3.2.1)(64bit)
libsmime3.so(NSS_3.3)(64bit)
libsmime3.so(NSS_3.4)(64bit)
libsmime3.so(NSS_3.4.1)(64bit)
libsmime3.so(NSS_3.6)(64bit)
libsmime3.so(NSS_3.7)(64bit)
libsmime3.so(NSS_3.7.2)(64bit)
libsmime3.so(NSS_3.8)(64bit)
libsmime3.so(NSS_3.9)(64bit)
libsmime3.so(NSS_3.9.3)(64bit)
libsoftokn3.so()(64bit)
libsoftokn3.so(NSS_3.4)(64bit)
libsoftokn3.so(NSS_3.52)(64bit)
libssl3.so()(64bit)
libssl3.so(NSS_3.11.4)(64bit)
libssl3.so(NSS_3.11.8)(64bit)
libssl3.so(NSS_3.12.10)(64bit)
libssl3.so(NSS_3.12.6)(64bit)
libssl3.so(NSS_3.13)(64bit)
libssl3.so(NSS_3.13.2)(64bit)
libssl3.so(NSS_3.14)(64bit)
libssl3.so(NSS_3.15)(64bit)
libssl3.so(NSS_3.15.4)(64bit)
libssl3.so(NSS_3.2)(64bit)
libssl3.so(NSS_3.2.1)(64bit)
libssl3.so(NSS_3.20)(64bit)
libssl3.so(NSS_3.21)(64bit)
libssl3.so(NSS_3.22)(64bit)
libssl3.so(NSS_3.23)(64bit)
libssl3.so(NSS_3.24)(64bit)
libssl3.so(NSS_3.27)(64bit)
libssl3.so(NSS_3.28)(64bit)
libssl3.so(NSS_3.30)(64bit)
libssl3.so(NSS_3.30.0.1)(64bit)
libssl3.so(NSS_3.33)(64bit)
libssl3.so(NSS_3.4)(64bit)
libssl3.so(NSS_3.7.4)(64bit)
libxul.so()(64bit)
libxul.so(xul84)(64bit)
metainfo()
metainfo(firefox.appdata.xml)
mimehandler(application/vnd.mozilla.xul+xml)
mimehandler(application/xhtml+xml)
mimehandler(text/html)
mimehandler(text/mml)
mimehandler(text/xml)
mimehandler(x-scheme-handler/http)
mimehandler(x-scheme-handler/https)
webclient
~~~

In the buildroot, it now gets pulled in instead of `nss*`. It seems this might break rubygem-activestorage in some way:

https://koschei.fedoraproject.org/package/rubygem-activestorage?collection=f34

Comment 13 Vít Ondruch 2020-12-17 16:05:30 UTC
And icecat is doing the same 🤦‍♂️

Comment 14 Vít Ondruch 2020-12-17 16:13:02 UTC
(In reply to Vít Ondruch from comment #12)
Reported separately as bug 1908791


(In reply to Vít Ondruch from comment #13)
Reported as bug 1908792

Comment 15 Dominik 'Rathann' Mierzejewski 2020-12-17 23:21:46 UTC
(In reply to Vít Ondruch from comment #14)
> (In reply to Vít Ondruch from comment #12)
> Reported separately as bug 1908791

This is essentially a duplicate of my bug 1582116 which I reported 2.5 years ago. No package should expose its private libraries in Provides:, bundled or not.

Thunderbird also does this, see bug 1582120 .

> (In reply to Vít Ondruch from comment #13)
> Reported as bug 1908792

Thanks.

Comment 16 Antonio T. sagitter 2020-12-18 13:08:32 UTC
(In reply to Vít Ondruch from comment #13)
> And icecat is doing the same 🤦‍♂️

Fixed: https://src.fedoraproject.org/rpms/icecat/c/17a41178bbdb9436e98e1faf4fd47fe2e7f34d4d?branch=master

I'm sorry for this drawback.

Comment 17 Bob Relyea 2020-12-18 16:55:15 UTC
No we definitely should not use bundled NSS. That turns off all policy controls.

I recommended in the original nss-3.59-2 build a patch to firefox to turn SHA1 general signatures back on until Firefox stops signing add-ons with sha1.

The code is:

/* Sets the NSS_USE_ALG_IN_ANY_SIGNATURE bit. 
 * does not change NSS_USE_ALG_IN_CERT_SIGNATURE,
 * so policy will still disable use of sha1 in
 * certificate related signature processing. */
rv = NSS_SetAlgorithmPolicy(SEC_OID_SHA1, NSS_USE_ALG_IN_ANY_SIGNATURE, 0);

/* checking rv is optional here, more likely to give a nice 
 * error message if policy is locked */

This will allow firefox to continue using sha1 signatures without affecting
other application.

Comment 18 Adam Williamson 2020-12-21 17:22:04 UTC
Interesting consequence of this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1909801 . :D

Comment 19 Adam Williamson 2020-12-28 18:00:14 UTC
So for the record this bug is back because mstransky switched Firefox back to building against system NSS, but did not patch it as Bob recommended to still allow SHA-1 signatures. I'll see if I can do that.

Comment 20 Martin Stransky 2021-01-02 08:06:56 UTC
(In reply to Adam Williamson from comment #19)
> So for the record this bug is back because mstransky switched Firefox back
> to building against system NSS, but did not patch it as Bob recommended to
> still allow SHA-1 signatures. I'll see if I can do that.

I'm going to look at it over weekend. I'd also like to open firefox/thunderbird commits for provenpackagers to allow to deliver such small changes.

Comment 21 Adam Williamson 2021-01-02 16:57:57 UTC
FWIW I did try to do it, but couldn't find the right place to patch so that add-on install was actually affected...

Comment 22 Kevin Fenzi 2021-01-02 19:16:06 UTC
(In reply to Martin Stransky from comment #20)
>
> I'm going to look at it over weekend. I'd also like to open
> firefox/thunderbird commits for provenpackagers to allow to deliver such
> small changes.

If there's no longer any concerns about doing this, this is just a config change in fedora-infrastructure. :) I guess open a ticket in https://pagure.io/fedora-infrastructure and we can change it.

Comment 23 Martin Stransky 2021-01-03 20:59:56 UTC
Bob, I have no idea where to apply the policy change. Can you please create a patch for it or guide me here?
Thanks.

Comment 24 Martin Stransky 2021-01-03 21:14:34 UTC
(In reply to Kevin Fenzi from comment #22)
> If there's no longer any concerns about doing this, this is just a config
> change in fedora-infrastructure. :) I guess open a ticket in
> https://pagure.io/fedora-infrastructure and we can change it.

Filed as https://pagure.io/fedora-infrastructure/issue/9557
Thanks.

Comment 25 Bob Relyea 2021-01-05 19:03:02 UTC
The simplest thing is to just put it after the NSS_Initialize (or NSS_Init or NSS_InitReadWrite. I'm not sure which one Firefox uses, I think it's NSS_InitReadWrite) call.

Ideally it would be in the prefs system, but I'm not familiar with the prefs code in Mozilla.

bob

Comment 26 Martin Stransky 2021-01-08 21:37:48 UTC
Looks like NSS_Initialize() is used, there's a backtrace:

#0  0x00007fffe3e0a360 in NSS_Initialize () at /lib64/libnss3.so
#1  0x00007fffe52a5f9b in mozilla::psm::InitializeNSS(nsTSubstring<char> const&, mozilla::psm::NSSDBConfig, mozilla::psm::PKCS11DBConfig)
    (dir=..., nssDbConfig=mozilla::psm::NSSDBConfig::ReadWrite, pkcs11DbConfig=mozilla::psm::PKCS11DBConfig::LoadModules)
    at /raid/CVS/firefox/firefox-84.0.2/security/certverifier/NSSCertDBTrustDomain.cpp:1617
#2  0x00007fffec6d41e8 in InitializeNSSWithFallbacks(nsACString const&, bool, bool) (profilePath=..., nocertdb=false, safeMode=false)
    at /raid/CVS/firefox/firefox-84.0.2/security/manager/ssl/nsNSSComponent.cpp:1893
#3  0x00007fffec6d4b1a in nsNSSComponent::InitializeNSS() (this=0x7fffc4fbda80) at /raid/CVS/firefox/firefox-84.0.2/security/manager/ssl/nsNSSComponent.cpp:2029
#4  0x00007fffec6d6158 in nsNSSComponent::Init() (this=0x7fffc4fbda80) at /raid/CVS/firefox/firefox-84.0.2/security/manager/ssl/nsNSSComponent.cpp:2315

Comment 27 Bob Relyea 2021-01-08 22:49:42 UTC
So you just need to add it in mozilla::psm::InitializeNSS, just after the NSS_Initialize call (it looks like it's in security/certverifier/NSSCertDBTrustDomain.cpp).

Comment 28 Martin Stransky 2021-01-11 12:47:42 UTC
Added to firefox-84.0.2-2.
Thanks.

Comment 29 Bob Relyea 2021-01-12 16:21:11 UTC
*** Bug 1912234 has been marked as a duplicate of this bug. ***

Comment 30 Adam Williamson 2021-01-13 17:19:14 UTC
openQA tests passed in today's compose (with the fix). Thanks!


Note You need to log in before you can comment on or make changes to this bug.