2086788 - Firefox 115 ESR may still trust the compromised eMudhra certificates

Status: VERIFIED FIXED

(Core :: Security: PSM, defect, P1)

Description

[Ray Satiro]

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

Steps to reproduce

In a clean profile with Firefox 115.43.1 observe that it trusts the compromised eMudhra certificates:

https://emudhra.we-have-a-problem.com/#check

Refer to the original report from dftf-stu at github:

https://github.com/galadran/we-have-a-problem.com/issues/168

Actual results

The results are "Insecure" which means the certificates are still trusted.

Expected results

The certificates should not be trusted and the connections should not succeed.

Comment 1

[Ray Satiro]

Related bug 2084379

Comment 2

[JACOB DURHAM]

Reproduced on Firefox 115.44.0esr (win64, clean profile). The cause is startup timing specific to ESR 115.

On ESR 115, RemoteSecuritySettings.init(), which loads OneCRL into cert_storage, is only called from _scheduleBestEffortUserIdleTasks(). Those tasks wait for 20 seconds with no user input, and the comment above them says they "may never be called if the user is never idle for the requisite time." Release and ESR 153 call it from browser-idle-startup since Bug 1988052, which was never uplifted to ESR 115. The emSign ECC Root CA - G3 root these chains lead to is still a trusted built-in (certdata), so until init() runs nothing blocks them.

What I ran: a clean profile driven over Marionette, which leaves services.settings.server pointed at a dummy, so only the bundled dump is involved. At each step I read RemoteSecuritySettings._initialized and getRevocationState() for EM DV TLS CA - G3B, using the issuer and serial from test_onecrl_loads_bundle.js.

• About 4 seconds after launch: _initialized false, G3B not revoked, and the test page reports 13, 14 and 12 of 14 chains trusted across three runs. The emSign-chained hosts connected every time. Most of the -aaa- hosts connected too, varying by run.
• The idle trigger never fired on its own while I was using the machine. In runs of up to 172 seconds, nsIUserIdleService.idleTime never got past 13 seconds, and _initialized stayed false the whole time.
• Calling BrowserGlue's own _lateTasksIdleObserver(idleService, "idle"), which is what the idle service calls after 20 seconds, ran init() within 3 seconds. G3B then showed as revoked, and the test page reported 0 of 14.

So the bundled dump and the Bug 2084311 fix work on 115.44.0esr once init() runs. What's missing is that init() doesn't run until the user has been idle for 20 seconds, which may never happen. The new test calls init() directly, so it would not catch this. On 115.43.1, init() also does not load the dump, so the entries depend on a Remote Settings sync after the idle trigger as well. I didn't test 115.43.1.

Moving RemoteSecuritySettingsInit on ESR 115 into _scheduleStartupIdleTasks() would match what Bug 1988052 did for Release and ESR 153.

Comment 3

[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 4

[John Schanck [:jschanck]]

Attachment: Bug 2086788 - initialize RemoteSecuritySettings as a startup idle task (esr115).

Comment 5

[Phabricator Automation]

firefox-esr115 Uplift Approval Request

• User impact if declined/Reason for urgency: OneCRL revocation data is not available until the user has been idle for 20 seconds, which may not happen.
• Code covered by automated testing?: no
• Fix verified in Nightly?: no
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: In a new profile, visit https://emudhra.we-have-a-problem.com/ within 20 seconds of startup. Ensure that all rows in the "Does your client still trust the compromised intermediates?" table show a green checkmark and the text "Did not connect".
• Risk associated with taking this patch: low
• Explanation of risk level: RemoteSecuritySettings initialization does very little actual work, so moving it earlier in startup should not significantly affect startup performance.
• String changes made/needed?: none
• Is Android affected?: no

Comment 6

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/62d69dc7961f

Comment 7

[Simona Badau, Desktop Test Engineering]

Reproduced the initial issue using Firefox 115.43.1 ESR (Build ID: 20261019140107) on macOS 26 - the insecure results are displayed in the "Does your client still trust the compromised intermediates?" table when using a new profile.

Verified as fixed using Firefox 115.45.0 ESR (Treeherder build, Build ID: 20261029155645) on macOS 26, Ubuntu 24.04, and Windows 11 - all rows in the "Does your client still trust the compromised intermediates?" table display a green checkmark and the text "Did not connect".

Comment 8

[Ray Satiro]

Thanks for the quick turnaround everyone.

I can't find any nightly esr builds on the FTP server, where are you getting the builds? Does this address enterprise users who many not receive the certificate updates or have their own update server? In other words, is the included certificate bundle fixed to distrust the certs or what happens if the revocation list can't be updated? Like if you launch a new profile with the network disabled and go into certs are the certs there and trusted?