Closed Bug 1823720 (CVE-2023-5729) Opened 1 year ago Closed 10 months ago

Obscured Fullscreen by Launching Security Credential Setup


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




119 Branch
Tracking Status
firefox-esr102 --- wontfix
firefox-esr115 - wontfix
firefox115 --- wontfix
firefox116 --- wontfix
firefox117 --- wontfix
firefox118 - wontfix
firefox119 + fixed


(Reporter: fazim.pentester, Assigned: jschanck)



(Keywords: csectype-spoof, reporter-external, sec-low, Whiteboard: [reporter-external] [client-bounty-form] [verif?][adv-main119+])


(4 files, 2 obsolete files)

Attached file 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.
Flags: sec-bounty?
Attached video demo.mp4

Video Demonstration

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?

Group: firefox-core-security → dom-core-security
Component: Security → DOM: Web Authentication
Flags: needinfo?(ckerschb)
Product: Firefox → Core

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

Flags: needinfo?(ckerschb) → needinfo?(jschanck)

(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.

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 somehow tricks the user into creating a credential for

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?

Flags: needinfo?(jschanck)

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(jschanck)

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?

Flags: needinfo?(echen)

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}( 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.

friendly ping

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

Depends on: CVE-2023-4051
Flags: needinfo?(echen)
See Also: CVE-2023-4051

(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?

Flags: needinfo?(echen)

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.

Flags: needinfo?(echen) → needinfo?(gijskruitbosch+bugs)

(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.

Flags: needinfo?(gijskruitbosch+bugs)

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

Flags: needinfo?(jschanck)

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

On Windows the UI is presented by the platform. On Mac and Linux we use 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?

Flags: needinfo?(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.

Flags: needinfo?(jschanck)
Assignee: nobody → jschanck
Ever confirmed: true
Severity: -- → S3
Priority: -- → P2

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
Attachment #9344744 - Flags: sec-approval?

sec-moderate bugs don't require sec-approval

Attachment #9344744 - Flags: sec-approval?
Flags: needinfo?(jschanck)

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.

Flags: needinfo?(fbraun)

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

Flags: needinfo?(fbraun) → needinfo?(jschanck)

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

Flags: needinfo?(jschanck)

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

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.
Attachment #9344744 - Attachment is obsolete: true

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.

Pushed by
prevent some fullscreen states while WebAuthn prompts are shown. r=edgar,keeler
Group: dom-core-security → core-security-release
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → 119 Branch

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.

Flags: needinfo?(jschanck)

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.

Keywords: sec-moderatesec-low

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!

Flags: sec-bounty? → sec-bounty-

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

(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?

Flags: needinfo?(dveditz)

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.

QA Whiteboard: [post-critsmash-triage]
Flags: qe-verify-
Whiteboard: [reporter-external] [client-bounty-form] [verif?] → [reporter-external] [client-bounty-form] [verif?][adv-main119+]
Attached file advisory.txt (obsolete) —
Attached file advisory.txt
Attachment #9359584 - Attachment is obsolete: true
Alias: CVE-2023-5729
Flags: needinfo?(dveditz)

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

Group: core-security-release
Flags: sec-bounty-hof+
You need to log in before you can comment on or make changes to this bug.