2084379 - Firefox ESR 153.5.1 source includes NSS 3.125 instead of NSS 3.131.1 which supposed to protect from eMudhra compromise

Status: RESOLVED DUPLICATE of bug 2088179

(Core :: Security: PSM, defect)

Description

[Goodzilla]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:153.0) Gecko/20100101 Firefox/153.0

Steps to reproduce

I compiled icecat by using "c6888848f90e7ebeacad38725b9bbbfe7c9bea7078098d47a2cf2c1ff3e18b83 source/firefox-153.5.1esr.source.tar.xz" source and it can't pass the first 6 bad host test and passess the rest in https://emudhra.we-have-a-problem.com/

I read this https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/
And I learnt that this issue was fixed with NSS 3.131.1 but about:support in icecat 153.5.1 tells me NSS version is 3.125. So i assume Firefox source came with that old version.

I tried with Debian 13's Firefox ESR 153.5.0. and it didn't connect any bad hosts and passed the test because of OneCRL thing.

Isn't the source supposed to be come with NSS 3.131.1?

Actual results

NSS version is old.

Expected results

NSS version should be 3.131.1

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Security: PSM' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Dana Keeler (she/her) [:keeler]]

Firefox is protected by remote settings/OneCRL in this case. The change you're looking for in ESR 153.5.0 is https://hg-edge.mozilla.org/releases/mozilla-esr153/diff/ddfd2b3eb9d794929dc6f7887c435c210c65ba67/services/settings/dumps/security-state/onecrl.json
If icecat doesn't use OneCRL, then it makes sense it would still trust those intermediates. Speaking of, what do you mean by "because of OneCRL thing"?

Comment 3

[Goodzilla]

(In reply to Dana Keeler (she/her) [:keeler] from comment #2)

Firefox is protected by remote settings/OneCRL in this case. The change you're looking for in ESR 153.5.0 is https://hg-edge.mozilla.org/releases/mozilla-esr153/diff/ddfd2b3eb9d794929dc6f7887c435c210c65ba67/services/settings/dumps/security-state/onecrl.json
If icecat doesn't use OneCRL, then it makes sense it would still trust those intermediates. Speaking of, what do you mean by "because of OneCRL thing"?

Right. It seems Icecat removes that feature. I have nothing to say after thinking about it since Mozilla doesn't have to take derivatives into account. I was just expecting NSS would be patched. I didn't mean something offensive by saying "because of OneCRL thing".

Comment 4

[Joonas Niilola]

Still, an nss-esr version release update with the emudhra fixes ASAP would be appreciated since LTS distributions can run nss-esr system-wide.

Comment 5

[Goodzilla]

I don't know if it was icecat or mozilla fixed this issue but it passes all tests now with "91cb675ddfc678255f57ecd7aad498501961577686d19c1947a82b14edea7f25 source/firefox-153.6.0esr.source.tar.xz".

Comment 6

[JACOB DURHAM]

On comment 4: the root removals that went into NSS 3.131.1 on 20 October (Bug 2084101 for emSign ECC Root CA - G3, Bug 2083709 for emSign Root CA - C1 and emSign ECC Root CA - C3) have not reached either Firefox ESR or the NSS ESR line:

• ESR 153.6.0 builds NSS 3.125 and still includes emSign ECC Root CA - G3 as a trusted root (certdata).
• ESR 115.44.0 builds NSS 3.90.6, with the same root (certdata).
• NSS_3_90_BRANCH has not changed since 3.90.6 on 13 April.

Both ESRs rely on OneCRL to block the compromised intermediates.

On comment 5: 153.6.0 has the same NSS and the same root as 153.5.1, so NSS doesn't explain the difference. The likely change is Bug 2084311, which makes Firefox load the OneCRL list bundled with the build at startup instead of waiting for a Remote Settings sync. That would cover a build that doesn't sync Remote Settings.

ESR 115 has a separate OneCRL startup timing problem, reproduced in Bug 2086788.

Comment 7

[Joonas Niilola]

Also downstreams can't patch the earlier nss's due to NSS_BUILTINS_LIBRARY_VERSION conflicts, though, it'd be possible to match it with the current 3.132 but it means the next official nss-esr release must do the same.

Anna, could you take a look / roll the process for an nss-esr update?

Comment 8

[JACOB DURHAM]

(In reply to Juippis from comment 7)

On the NSS_BUILTINS_LIBRARY_VERSION conflict: where NSS already loads p11-kit-trust.so in place of libnssckbi.so, the root removals from NSS 3.131.1 can be applied through the system trust store without patching builtins or matching a library version.

On Fedora/RHEL, place the PEMs for emSign ECC Root CA - G3, emSign Root CA - C1, and emSign ECC Root CA - C3 in /etc/pki/ca-trust/source/blocklist/ and run update-ca-trust extract (RHEL 9 shared system certificates; p11-kit trust module; Using the Trust Policy Module with NSS). The same blocklist path can take the eight compromised G3B/G3C intermediates if a OneCRL-style block is needed for system NSS consumers (Mozilla blog, 20 Oct 2026; root removals tracked in Bug 2084101 and Bug 2083709).

This only helps consumers that use p11-kit-trust.so as builtins. Debian's libnss3 does not do that by default. Firefox's own bundled NSS still relies on OneCRL (comment 2).

Separately, backporting Bug 2084311 (bundled OneCRL at startup) to ESR 115 would cover the timing gap in Bug 2086788. An nss-esr release with the root removals remains the durable fix for the version conflict in comment 7.