1823720 - (CVE-2023-5729) Obscured Fullscreen by Launching Security Credential Setup

Status: RESOLVED FIXED

(Core :: DOM: Web Authentication, defect, P2)

Description

[Shaheen Fazim]

Attachment: spoof.html

In Firefox for Windows, launching Windows Security Credential Setup using navigator.credentials() can obscure the fullscreen toast Text.

Steps to Reproduce:

1. Download the spoof.html file.
2. Open the spoof.html file in Firefox for Windows.
3. Click anywhere on the webpage.

Comment 1

[Shaheen Fazim]

Attachment: demo.mp4

Video Demonstration

Comment 2

[:Gijs (he/him)]

Looks like we're putting website-provided text into the OS dialog. That generally feels like something where we'll need to provide some kind of sanitization. It also seems like, just like in bug 1816287, we may want to exit fullscreen when this happens.

Christoph, do you know who knows about the webauth/credential implementation here?

Comment 3

[Christoph Kerschbaumer [:ckerschb}]

John is our WebAuthN go-to person. He offered to take a look.
302 to him.

Comment 4

[:Gijs (he/him)]

(In reply to :Gijs (he/him) from comment #2)

It also seems like, just like in bug 1816287, we may want to exit fullscreen when this happens.

I was thinking of bug 1821884 here, though it was discussed in both.

Comment 5

[John Schanck [:jschanck]]

I could be convinced that we should exit fullscreen here. But I don't actually see a security risk. The worst-case scenario is that example.com somehow tricks the user into creating a credential for example.com.

You could argue that displaying the newlines in the dialog is a bug in the Windows WebAuthn API. There's a relevant SHOULD clause in Section 5.4.1:

Clients SHOULD perform enforcement, as prescribed in Section 3.4.3 of [RFC8265]
for the UsernameCasePreserved Profile of the PRECIS IdentifierClass [RFC8264],
on name's value prior to displaying the value to the user or including the value
as a parameter of the authenticatorMakeCredential operation.

And a similar SHOULD clause for the relying party's behavior. But it's not a MUST.

:edgar, if we did want to exit fullscreen, what's the preferred way to do that? Is there a way to temporarily prohibit fullscreen requests?

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jschanck, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 7

[Daniel Veditz [:dveditz]]

On the mac the dialog doesn't come anywhere geographicalluy close to the fullscreen toast, let alone obscure it. Even in the movie this spoof doesn't fully hide it on Windows: it's clearly suspicious behavior. In addition, the security dialog itself will be a surprise to most users and raise even more suspicion about the site.

Chrome on mac starts to go into fullscreen and then pops right back out when the webauthn dialog shows up. That would fix the problem, though we should be consistent. Is it never appropriate to request a permission while you're in fullscreen? It would be simplest to say "no; it's never appropriate". We wouldn't have to worry about sites trying to create fake permission dialogs (but they couldn't get any privileges so I can't think of a reason to do that). We would only ever show the permission dialogs when we had browser chrome available to show it's a legit prompt, and to show the true site context (the fullscreen site might "fake navigate" and then try to get a victim to grant permissions to it thinking they're on some other site they trust. Also, when we're not in fullscreen the controls to fix mis-granted permissions are easy to notice and use.

On balance I think it will be safer to prevent permission dialogs in fullscreen, either by suppressing them (auto reject?) or by canceling fullscreen to ask. But I could imagine a case or two where that could get awkward. For example, you're browsing a fullscreen map and click the button to jump to your location: the site now has to ask for geolocation permission to do that. Or you're in a fullscreen game app and it has an option to let you create an avatar based on a picture of you, and needs to get permission to use the webcam.

We could do both: reject/suppress permission requests for a few seconds (5? 10?) when we start the fullscreen transition, but allow them after that. We could also consider rejecting requestFullscreen() calls if there's already an unresolved permission request in progress. I might be inventing new race conditions for us to lose :-)

Edgar: what do you think?

Comment 8

[Daniel Veditz [:dveditz]]

Safari seems to have a race condition. Sometimes the passkey dialog comes up first and then I enter fullscreen, a bit more of the time I go into fullscreen first and then am take back to the original Desktop to futz with the security key. After that I'm not taken back to the fullscreen content, but it's still open on the other desktop. You've got to figure out your own way back over there (4-finger side-swipe or Control-right-arrow) or click on the empty tab to pull it back from fullscreen. (Note: the testcase only works in Safari 16.4. You have to change it to use webkitRequestFullscreen() in earlier versions). The Safari version of the prompt shows the full name text including the

So that's a lot about the fullscreen/prompt interaction, and that part might be fixed elsewhere than Web Authentication. But it seems pretty clear that Firefox and Safari, at least, aren't preparing the name strings are specified. We're supposed to make sure it conforms to the FreeForm class defined by RFC8264 and [RFC8266}(https://www.rfc-editor.org/rfc/rfc8266). Those forbid control characters which would take care of the newlines, but also a whole bunch of Unicode normalization that's similar to what's done for IDN domain names. Maybe this part should be spun out into it's own bug.

Comment 9

[Shaheen Fazim]

friendly ping

Comment 10

[Edgar Chen [:edgar]]

Lets wait for bug 1821884 to be resolved first, the solution there might help this as well.

Comment 11

[:Gijs (he/him)]

(In reply to Edgar Chen [:edgar] from comment #10)

Lets wait for bug 1821884 to be resolved first, the solution there might help this as well.

Did this work out ie has this been addressed by that fix?

Comment 12

[Edgar Chen [:edgar]]

This has been addressed by bug 1821884 on Windows, but not on Mac and Linux, because the credential popup doesn't cause the browser window to deactivate, so detecting activation doesn't work there.
Chrome and Safari both deactivate the browser window when credential popup is shown (at least the page receive blur event and lose the focus), it seems to me that we should do the same.
Gijs, do you know what might cause the difference between on Windows and other platforms? I suspect there are some difference in widget code, but not so sure.

Comment 13

[:Gijs (he/him)]

(In reply to Edgar Chen [:edgar] from comment #12)

Gijs, do you know what might cause the difference between on Windows and other platforms? I suspect there are some difference in widget code, but not so sure.

No, I don't know. Hopefully jschanck does. I'll ping on slack.

Comment 14

[John Schanck [:jschanck]]

On Windows the UI is presented by the platform. On Mac and Linux we use PopupNotifications.show here.

Comment 15

[:Gijs (he/him)]

(In reply to John Schanck [:jschanck] from comment #14)

On Windows the UI is presented by the platform. On Mac and Linux we use PopupNotifications.show here.

Thanks! If we passed the autofocus option to this call, it should steal focus as Edgar suggested in comment 12. Is there any reason not to do that? And do we have a security delay implemented on any buttons this popup shows to prevent clickjacking / keyjacking, if we do start autofocusing it?

Comment 16

[John Schanck [:jschanck]]

Passing autofocus seems to work, thanks! And yes, there's a security delay here. The delay is configured by the security.notification_enable_delay pref and defaults to 500ms.

Comment 17

[John Schanck [:jschanck]]

Attachment: Bug 1823720 - Autofocus WebAuthn prompts. r=keeler

Comment 18

[John Schanck [:jschanck]]

Comment on attachment 9344744 [details]
Bug 1823720 - Autofocus WebAuthn prompts. r=keeler

Security Approval Request

• How easily could an exploit be constructed based on the patch?: Not easily. The patch aligns our behavior on MacOS and Linux with our behavior on Windows post-Bug 1821884. While it makes sense to align our behavior, the spoofing proof-of-concept was not very convincing on MacOS and Linux to begin with.
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: No
• Which older supported branches are affected by this flaw?: all
• If not all supported branches, which bug introduced the flaw?: None
• Do you have backports for the affected branches?: No
• If not, how different, hard to create, and risky will they be?: The patch should apply cleanly.
• How likely is this patch to cause regressions; how much testing does it need?: I don't see any way that autofocusing the prompts could cause regressions. The prompts are sensitive to visibility changes, but not focus changes. There are unit tests that cover all meaningful interactions with the prompts.
• Is Android affected?: No

Comment 19

[Ryan VanderMeulen [:RyanVM]]

sec-moderate bugs don't require sec-approval

Comment 20

[BugBot [:suhaib / :marco/ :calixte]]

The bug is marked as tracked for firefox117 (nightly). However, the bug still has low severity.

:freddy, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 21

[Frederik Braun [:freddy]]

John, do you still think this should be kept as tracked and increased to S2 or no longer tracked for 117?

Comment 22

[John Schanck [:jschanck]]

No longer tracked for 117, thanks. I will get to it for 118.

Comment 23

[Frederik Braun [:freddy]]

[Tracking Requested - why for this release]: Unlikely we're going to make 117, so requesting to be tracked for 118.

Comment 24

[John Schanck [:jschanck]]

Attachment: Bug 1823720 - prevent some fullscreen states while WebAuthn prompts are shown. r?edgar r=keeler!

This prevents fullscreen states that hide chrome while WebAuthn prompts are shown. Specifically, it

1. ensures that the navigation toolbox is shown in fullscreen windows, and
2. disallows fullscreen DOM elements.

Comment 25

[John Schanck [:jschanck]]

Unfortunately the autofocus trick isn't compatible with some assumptions made by our tests (and, worse, by the webauthn wpts), so I've posted a new patch using a different approach.

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/730394fa6984
prevent some fullscreen states while WebAuthn prompts are shown. r=edgar,keeler

Comment 27

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

https://hg.mozilla.org/mozilla-central/rev/730394fa6984

Comment 28

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:jschanck, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox118 to wontfix.

For more information, please visit BugBot documentation.

Comment 29

[Daniel Veditz [:dveditz]]

changing severity to sec-low, and even that seems generous. This attack does not hide the toast movement and the transition animation still happens. Also, popping up a Windows Hello dialog when you're not expecting it is very suspicious.

Comment 30

[Frederik Braun [:freddy]]

Shaheen Fazim, thank you for reporting this bug to us. Ultimately, we were not fully convinced that this is a very useful spoof, as explained by Dan in the comment above. We generally do not pay a bounty for bugs rated sec-low. Looking forward to your next submission!

Comment 31

[John Schanck [:jschanck]]

Not requesting beta uplift as the change is cosmetic on mac / linux.

Comment 32

[Shaheen Fazim]

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

changing severity to sec-low, and even that seems generous. This attack does not hide the toast movement and the transition animation still happens. Also, popping up a Windows Hello dialog when you're not expecting it is very suspicious.

Hello, even though a fullscreen toast animation or movement is displayed, an attacker could use the same background color as the color the toast is using. Consequently, they could conceal it in a manner that leaves the victim unaware, as the toast text is effectively hidden by using the Windows Hello dialogue. Since Windows Hello is an OS dialogue, the victim will not be aware if the site has launched. When he/she cancels it, the site can easily spoof it. Could you please reevaluate the issue and elevate the security severity, as this is similar to other fullscreen spoofs?

Comment 33

[Shaheen Fazim]

The key point I am emphasizing here is that this method effectively conceals the text informing the user that the site is in fullscreen mode. I was able to achieve this using the mentioned approach. I believe this constitutes a valid security concern, and I hope you find it a reasonable basis for a bounty.

Comment 34

[Tyson Smith [:tsmith]]

Attachment: advisory.txt

Comment 35

[Tyson Smith [:tsmith]]

Attachment: advisory.txt

Comment 36

[Daniel Veditz [:dveditz]]

Bulk-unhiding security bugs fixed in Firefox 119-121 (Fall 2023). Use "moo-doctrine-subsidy" to filter