1721220 - (CVE-2022-34469) TLS certificate exceptions are possible despite HSTS

Status: RESOLVED FIXED

(GeckoView :: General, defect, P1)

Description

[Peter Gerber (:pege)]

On Firefox 90 for Android and Nightly, on websites where previously an HSTS header has been received and is still an effect, certificate errors have an "Accept the Risk and Continue" button.

As per RFC 6797 Section 12.1 of the HSTS specification, such a button should not be present:

Failing secure connection establishment on any warnings or errors
(per Section 8.4 ("Errors in Secure Transport Establishment")) should
be done with "no user recourse". This means that the user should not
be presented with a dialog giving her the option to proceed. Rather,
it should be treated similarly to a server error where there is
nothing further the user can do with respect to interacting with the
target web application, other than wait and retry.

In Firefox Desktop, this is done correctly and it is not possible proceed to the web page if certificate validation fails:

https://gitlab.com/uploads/-/system/user/1406255/480f835f498d94c1b8576e52216345ac/ff.png

Steps to Reproduce - includeSubDomains

1. Go to https://tocco.ch to pick up the following HSTS header:

   Strict-Transport-Security: max-age=2592000;includeSubDomains

2. Go to http://abc.tocco.ch. As requested by the HSTS header, the request is upgraded to HTTPS and a certificate error is shown. It's possible to continue, however.

Here we use a domain that uses includeSubDomains as it is easier to reproduce; there is no need to replace the certificate after fetching the HSTS header. However, I also tried this on a page without includeSubDomains by temporarily replacing the certificate with a invalid one. The result was the same.

Steps to Reproduce - Preloaded

1. Go to https://may.arbitrary.ch. Incorrectly, an "Accept the Risk and Continue" presented. The button (luckily) doesn't actually work.

arbitrary.ch is on the HSTS preload list and it should be impossible to visit it or any subdomain if a certificate error is presented.

Comment 1

[Peter Gerber (:pege)]

Attachment: Firefox Desktop, here handling is correct.

Comment 2

[Daniel Veditz [:dveditz]]

rating this sec-moderate because it requires the user to explicitly bypass the scary warning, but this is wrong and dangerous.

Comment 3

[Sebastian Kaspari (:sebastian; :pocmo)]

@agi: Afaik when showing an error page from A-C then we cannot know whether it's okay to show this?

Comment 4

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

I don't understand why this is a security bug if the only problem here is that we present a button? The error cannot be actually bypassed, is that correct? I see the includeSubDomains can actually be bypassed.

Sebastian, yeah I don't think you can (but I need to double check). The solution for all these problems is a chrome-only API that can let you know when an error is overridable or not (see Bug 1696841 Comment 15 and later)

Comment 5

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

Interestingly when I try to navigate to abc.tocco.ch after navigating to tocco.ch I don't get upgraded to HTTPS. I wonder if HSTS is also failing here (at least for me)

Comment 6

[Peter Gerber (:pege)]

I don't understand why this is a security bug if the only problem here is that we present a button? The error cannot be actually bypassed, is that correct?

@agi, no this is wrong, the error can be bypassed. That is the Accept the Risk and Continue works. The one exception here is domains on the preload list. There the error can't be bypassed.

Comment 7

[Peter Gerber (:pege)]

Interestingly when I try to navigate to abc.tocco.ch after navigating to tocco.ch I don't get upgraded to HTTPS. I wonder if HSTS is also failing here (at least for me)

I just noticed that too. Looks like the is something wrong on the Nightly builds. The icon appears to be wrong. When clicking into the URL bar I actually see an https:// address and even on the error page there is a strike though the lock icon. There also appears to be some issue when tapping on the lock icon, the certificate isn't shown.

(Looks like there was a certificate issued for abc.tocco.ch by accident. I removed it again. Just in case you wondered why no error was shown, that's why.)

Comment 8

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

(In reply to Peter Gerber (:pege) from comment #7)

Interestingly when I try to navigate to abc.tocco.ch after navigating to tocco.ch I don't get upgraded to HTTPS. I wonder if HSTS is also failing here (at least for me)

I just noticed that too. Looks like the is something wrong on the Nightly builds. The icon appears to be wrong. When clicking into the URL bar I actually see an https:// address and even on the error page there is a strike though the lock icon.

mh interesting, when clicking on the URL bar I see http://abc.tocco.ch and also the network developer tools do confirm it's connecting to the HTTP server. I'll debug a little bit to see what's going on there.

There also appears to be some issue when tapping on the lock icon, the certificate isn't shown.

Yes I noticed that too earlier and opened Bug 1723578 for that.

Comment 9

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

As to why we allow upgrading, this bit of info is stored in the cssClass property which GV doesn't use at all: https://searchfox.org/mozilla-central/rev/7b1de5e29d878cc163dec7beaf9b57a2f0f41aaa/docshell/base/nsDocShell.cpp#3515-3517 there's probably a lot of this kind of bugs around error pages.

Comment 10

[Kevin Brosnan [Ex-Mozilla]]

This look like we need GV work first to get the correct error codes.

Comment 11

[Emily Toop (:fluffyemily)]

We need to take a look at this and see what needs to happen and whether there are any dependencies on other teams.

Comment 12

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

I think most of the changes to make this happen are in nsDocShell, which is not really owned by anyone AFAIK. I have an old patch that fixes this that I can resurrect.

Comment 13

[Chris Peterson [:cpeterson]]

We'd like to fix this bug in 101.

Comment 14

[Chris Peterson [:cpeterson]]

(In reply to Agi Sferro | :agi | [slow ni? rn sorry] | ⏰ PST | he/him from comment #12)

I think most of the changes to make this happen are in nsDocShell, which is not really owned by anyone AFAIK. I have an old patch that fixes this that I can resurrect.

Agi, do you think you will be able to fix this during the Nightly 101 cycle? This bug has the [geckoview:m101] tag.

Should we move this bug from the GeckoView::General component to some Core component?

Comment 15

[Cathy Lu [:calu]]

Attachment: Bug 1721220 - Add BAD_STS_CERT error

HSTS (HTTP Strict Transport Security) headers are added to inform browsers that the website should only access urls with https. Any attempts to access http will automatically be converted to https. The bug that this patch fixes is that even though Firefox has the HSTS header loaded, certificate error pages still have the “Accept risk and continue” button, when there should not be an option. This works on desktop but not on Android, so this patch creates a boolean when desktop determines it is a bad sts cert issue, by detecting if it is a sts host or a pinned host. Then it passes the new error code to HandleLoadError. This was manually tested by loading an HSTS header through this website https://preloaded-hsts.badssl.com/ and then accessing https://subdomain.preloaded-hsts.badssl.com/. It was verified that ERROR_BAD_STS_CERT was returned.

Comment 16

[Chris Peterson [:cpeterson]]

Cathy, will Fenix and GVE need to add frontend code to handle the new ERROR_BAD_STS_CERT error code? Or will their existing cert error handling cover this new error code?

Comment 17

[Cathy Lu [:calu]]

Hey Chris, yes they will need to handle the new error and not show the button "Accept Risk and Continue"

Comment 18

[Chris Peterson [:cpeterson]]

I filed a new Fenix bug for them to handle the new error: https://mozilla-hub.atlassian.net/browse/FNXV2-20458

Setting status-firefox101=wontfix because there's no need to uplift this fix if Fenix 101 isn't handling the new ERROR_BAD_STS_CERT error code.

Comment 19

[Cathy Lu [:calu]]

(In reply to Daniel Veditz [:dveditz] from comment #2)

rating this sec-moderate because it requires the user to explicitly bypass the scary warning, but this is wrong and dangerous.

Hey Daniel, would you be able to take a look at this and see if we should land or uplift the bug fix? Fenix isn't handling the new error code yet. Will this be a security problem if landed or uplifted?

Comment 20

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

Add BAD_STS_CERT error r=geckoview-reviewers,nika,agi,owlish
https://hg.mozilla.org/integration/autoland/rev/2a017ac54d0492d3cdbe1f0e7bde176e95185760
https://hg.mozilla.org/mozilla-central/rev/2a017ac54d04

Comment 21

[Tom Ritter [:tjr]]

Attachment: advisory.txt