1667179 - (CVE-2020-26957) OneCRL does not appear to be working in Fenix

Status: RESOLVED FIXED

(GeckoView :: General, defect, P1)

Description

[April King [:April]]

OneCRL (Remote Settings) does not appear to be working in Fenix, meaning that Fenix currently has no way to revoke misissued or malicious certificates. This may be related to bug 1625257, if Remote Settings uses storage.sync.

This was first reported here:
https://github.com/mozilla-mobile/fenix/issues/14597

With the thought that https://revoked.badssl.com/ was not added to OneCRL, and so therefore didn't trigger the revocation error. However, it was added in bug 1664854 and the error persisted, bringing to light the fact that OneCRL-based certificate revocation appears to be completely nonfunctional in Fenix.

:dveditz, should we remove this (currently innocuous) looking bug from Github?

Comment 1

[J.C. Jones [:jcj] (he/they)]

I've confirmed that the update pref we'd expect Gecko to increment on OneCRL updates remains uninitialized at 0 in Fenix Nightly, which agrees with the idea that OneCRL is not updating / has no data on Fenix.

Comment 2

[J.C. Jones [:jcj] (he/they)]

OneCRL is our mechanism for addressing compromise or malpractice ("misissuance") by Certificate Authorities, including those currently unknown (e.g., https://blog.mozilla.org/security/2019/08/21/protecting-our-users-in-kazakhstan/ ).

For most Firefox users, OneCRL is delivered in their install package (in /defaults/settings/security-state/onecrl.json, packaged here), and then the Kinto Client keeps it in-sync with periodic updates at Remote Settings; the deltas are typically about 100 bytes, consisting of a couple of strings, and occur on administrative action (e.g., rare, only when necessary). They do get broadcast by Megaphone, but normally on the daily kinto/remote settings check, Firefox gets OneCRL diffs, if any.

OneCRL today is larger than it needs to be, because Firefox 68 clients don't cleanly support removal from OneCRL. We intended for shorten OneCRL this week, but held off since Tor hasn't moved from ESR 68 yet. Anyway, typically the compressed OneCRL state is rolled into the installer and pretty small (540kB uncompressed, 72 kB with bz2).

Comment 3

[Kevin Brosnan [Ex-Mozilla]]

Who owns this Fenix/A-C or GV?

Comment 4

[Daniel Veditz [:dveditz]]

I think we can leave the public github issue alone for now (that is, don't try to hide it). There are other bugs noting that Focus, for example, also doesn't support OneCRL, and other places that mention testing against revoked.badssl.com so we'll probably just get dupes if we take it away. But we should stop poking at the GH version of this bug and continue here while trying to work out why it isn't working.

Comment 5

[Daniel Veditz [:dveditz]]

jc: would you call this sec-moderate or sec-high?

Comment 6

[J.C. Jones [:jcj] (he/they)]

I agree with sec-moderate. Obviously this is a mitigation so that in the event of a sec-critical or sec-high we can avoid spinning builds, but ultimately we can still lean on RelEng to make an immediate point release of Fenix at any hour of the day or night. We just... shouldn't have to.

Comment 7

[Sebastian Kaspari (:sebastian; :pocmo)]

@Snorp, Agi: This is probably more in your layer or below. I assume GeckoView should deal with that internally?

Comment 8

[[ex-Mozilla] Agi Sferro | :agi]

ni esawin in case he knows what's going on here.

Interestingly chrome doesn't block revoked.badssl.com either.

I see that we should have the onecrl.json file on mobile, trying to figure out why it's not working.

Comment 9

[[ex-Mozilla] Agi Sferro | :agi]

Looks like this is a miss from Bug 1526018 which moved the initialization code from somewhere in security/ to browser and did not include the code in mobile too... patch incoming.

Comment 10

[[ex-Mozilla] Agi Sferro | :agi]

Attachment: Bug 1667179 - Initialize OneCRL when GeckoView starts.

Comment 11

[April King [:April]]

(In reply to Agi Sferro | :agi | ⏰ PST | he/him from comment #8)

Interestingly chrome doesn't block revoked.badssl.com either.

Hmm, on which platform? Chrome desktop blocks it for me, as does Chrome on iOS.

(asking because I run badssl.com)

Comment 12

[[ex-Mozilla] Agi Sferro | :agi]

Attachment: revoked.badssl.com on Chrome Android

(In reply to April King [:April] from comment #11)

(In reply to Agi Sferro | :agi | ⏰ PST | he/him from comment #8)

Interestingly chrome doesn't block revoked.badssl.com either.

Hmm, on which platform? Chrome desktop blocks it for me, as does Chrome on iOS.

(asking because I run badssl.com)

On Android

Comment 13

[April King [:April]]

Ahh, got'cha. Yeah, I think it's coming at some point, but currently Chrome (Android) doesn't make use of CRLSet/Blacklist as it relies on Android's path discovery and verification.

Comment 14

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/integration/autoland/rev/1aa2dc4b280e4ac1d5d5742e1923d5d39c04c102
https://hg.mozilla.org/mozilla-central/rev/1aa2dc4b280e

Comment 15

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

In Fenix 84 https://revoked.badssl.com/ gets blocked but it loads in 83 but the central revision landed in 83. about:buildconfig says it should be included (tagged as devedition etc), might one of the dependencies have an older central revision hardcoded?

Comment 16

[[ex-Mozilla] Agi Sferro | :agi]

I think this is caused by the CRL list not being downloaded yet, could you try leaving the browser idle before testing? It works fine on my Fenix Beta (83).

Comment 17

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Let Firefox 83.0b10 idle twice >20 minutes, terminated app, launched it again, https://revoked.badssl.com/ still doesn't get blocked.

Comment 18

[Tom Ritter [:tjr] (OOTO until mid-August)]

Attachment: advisory.txt

Comment 19

[Tom Ritter [:tjr] (OOTO until mid-August)]

Attachment: advisory.txt