Chromium

FWIW, I discovered this accidentally while visiting Stack Overflow with an unmaximized window near the right edge of my screen, so it's not too difficult for others to discover.

It's also possible to have multiple FedCM bubbles open on different windows (see attached screenshot), so ✨imagine the possibilities✨.

Issue tracker shows a couple of non-security reports by @chromium.org users describing the same behavior, but don't mention the security impacts:

https://issues.chromium.org/issues/40261354 (filed March 2023)

https://issues.chromium.org/issues/40276254 (filed July 2023)

Thank you for the detailed report!

The POCs aren't quite as convincing when I tried on Linux, ChromeOS, and Mac since sometimes the positioning is off, but the idea is definitely there. Thank you for the screencasts as well.

yigu: Could you please take a look?

Setting medium severity on the basis that the positioning may be finicky for an attacker to get right.

Thanks for triage! I didn't spend too much time on perfecting the positioning, so with some more effort an attacker can make it more convincing across different environments.

Are those screenshots on Mac and (ChromeOS or Linux)? On Windows, modals are always within the browser window.

There are discrepancies in how modals are handled in some platforms. I'll look up some of my prior reports for citations shortly, but that's a somewhat known issue for all modal dialogs more broadly.

This is a relevant issue, focused on the Payment Request/Handler dialog: https://issues.chromium.org/issues/40058363

This comment from early 2022 indicates the plan was to not clip dialogs on Windows to align with Mac and other platforms: https://issues.chromium.org/issues/40058363#comment42

Not sure whether that's still the plan now. There's problems both ways, as noted in the discussion there. If clipped, we need to make sure the buttons can't be interacted with (otherwise you run into things like issue 40067462, issue 40055478, and many others).

Also see a bunch of related issues in this August 2023 comment: https://issues.chromium.org/issues/40067462#comment7

Otherwise various dialogs/bubbles being clipped by small windows are tracked in many dup'able issues, e.g.:

• https://crbug.com/chromium/1283234 (lots of discussion there), https://crbug.com/chromium/1196750 (cited above), https://crbug.com/chromium/1368222, > https://crbug.com/chromium/1258008, https://crbug.com/chromium/1280332, etc.

If you want, ask someone from Views team (or the relevant team) about their current plans for this, and other security issues they may be aware of for similarly-sensitive UIs.

In this week's backlog, I have a new security report for the FedCM modal being clipped and still being interactive in small windows on Windows, but that will likely be added to the pile of clipped-dialogs bugs.

I hadn't thought about your perspective of using modals to obscure other UIs, so I will need to experiment with that this week.

Also interesting: On Linux, bubbles and modals are also clipped but in a slightly different way than Windows.

Seems like this will be fixed soon on Linux per https://issues.chromium.org/issues/40058249#comment111

Thanks for fix Zachary and team, will verify once it lands on Canary.

re: #comment16, SGTM. Feel free to comment their response in the upcoming bug, since it's more relevant there.

Filed issue 341095528 for the FedCM modal dialog clipping.

Verified as fixed in 127.0.6485.0 Canary on Windows 10 Version 22H2 (Build 19045.4170), using all PoCs from report (and playing around with https://alesandroortiz.com/security/chromium/fedcm-placement.html to try to break it).

Also verified this prevents interacting with the bubble dialog when clipped in small windows.

Thanks for fixing!

Upon review, resetting back to medium severity (s1) based on security triage also impacts merge review and approval. Given that and this is a rather sizable change, declining merge approval for 125 (current Stable channel) and 124 (Extended Stable). This fix was already approved for 126 merge, so please feel free to merge to branch 6478 at this time.

I would concur with that plan (as long as it's not easier to revert and rework this fix and you are confident in the crash fix), but you'll want to coordinate with a release manager on the crash bug. I can only approve merge from a security standpoint. Since this merge was auto-approved since it was right after branching it was not reviewed for stability. So if to resolve the crash it would be easier to revert and re-work the fix for this issue, I would suggest that instead. We can't merge the fix if we don't have confidence that the crash will be resolved.

Thank you for the report, Alesandro. We had a pretty lengthy discussion about this issue during VRP Panel today and it was decided that this should not be considered a security bug. While you report does a good job of discussing the art of the possible in terms of potential issues to a user, actual harm or potential harm or security consequences to a user were not demonstrated in your report. The malicious origin displays clearly on the prompt and there is no crossing the line of death or obstruction of any important security UI that would result in a convincing spoof demonstrated in through your POC or report.

We did noticed that your comment #5 I didn't spend too much time on perfecting the positioning, so with some more effort an attacker can make it more convincing across different environments. If you are able demonstrate this issue in more convincing manner that demonstrates the potential user harm you purport here, we would be very happy to reassess for consideration of a potential VRP reward.

Hi Amy, thanks for the details about the VRP Panel discussion. I understand that Scenarios 1 and 3 might not meet the bar given mitigating factors, but I still think Scenario 2 (Bubble shown off screen (hidden login)) does meet the bar for security consequences to a user.

My understanding is that FedCM dialogs are considered sensitive UI and they should be protected like any other sensitive browser UI. If a user accepts a FedCM prompt, the page can obtain sensitive data, such as email, name, photo, and a token. Depending on the IDP, the token may allow an RP to use the IDP's API to obtain even more sensitive info or perform actions on behalf of the user on the IDP's products.

This makes FedCM dialogs similar to autofill or permission prompts, which also provide a page with sensitive info or capabilities. Providing autofill data or granting permissions without user awareness is considered a security issue. This should also apply to FedCM dialogs for the same reasons it applies to those other sensitive UIs.

Much like autofill and permission prompts, the FedCM bubble is already protected against some unintentional interactions, such as clickjacking. Autofill and permission prompts also protect against clickjacking and other forms of unintentional interaction, but the FedCM bubble didn't protect against unintentional interaction via offscreen rendering prior to the patch.

Unintentional interaction via offscreen rendering is demonstrated in Scenario 2: Bubble shown off screen (hidden login) (video: fedcm-offscreen.mp4).

Other reports of sensitive UI being offscreen and interactive have been considered security reports (e.g. issue 40058916 which impacted several UIs, including autofill and permission prompts).

there is no crossing the line of death

Technically, Scenario 3 (Bubble over another origin) essentially renders anywhere, including above the line of death, but as you mentioned, the origin display mitigates impacts in this scenario.

There are greater impacts when chained with issue 340893685 [1], but these impacts are probably more relevant in that other issue. I did want to mention it here in case it's relevant for this issue's classification and reward discussion.

[1] See https://issues.chromium.org/issues/340893685#comment2 for chained repro steps

Re: #comment5, that was in response to the shepherd's report of placement issues on non-Windows OSes (since I developed and tested the PoC on Windows):

The POCs aren't quite as convincing when I tried on Linux, ChromeOS, and Mac since sometimes the positioning is off, but the idea is definitely there

The videos still show the placements where they would have security impacts, and the PoCs probably repro the same on most Windows devices. I'm not sure if fixing placement on other OSes will help to further demonstrate security impacts, since demonstrating the placement on Windows should be sufficient.

Hi Alesandro, thanks for the response. I didn't have the opportunity to review all of this and respond with the consideration it deserves sooner.

We'll take a second look specifically at scenario 2. In reviewing your response, I did just reproduce this for myself (which I will admit I didn't attempt to do during panel for all the scenarios) and I can see the possible potential for security impact here, but I do want to note that for this scenario to come to fruition, there are a quite a few well-time gestures that must be done here. The click, then tab-tab-enter. When not timed well, this doesn't execute and doesn't result in the login. This is not to nit-pick here at all, but more to have a dialog around the potential for exploitability, which presents as fairly low.

But I do think this particular scenario of the off-window bubble warrants another review, which we'll do next week and get respond accordingly.

Thanks for the response and taking a second look.

there are a quite a few well-time gestures that must be done here. The click, then tab-tab-enter. When not timed well, this doesn't execute and doesn't result in the login.

I can improve the PoC to remove these timing issues. The gestures don't need to win a race, but instead wait long enough for the FedCM prompt to render (which isn't a long time). The Glitch-hosted IDPs might be slowing this down significantly, causing the repro to fail if the tab-tab-enter is done too soon (i.e. before the FedCM prompt is displayed).

Will provide an updated PoC by Tuesday so you can have it for the next VRP Panel. I'll use a locally-hosted IDP to remove unrealistically slow IDP response times from the equation (Glitch's response times are often not realistic by any means), and try to identify + remove any other timing issues.

This fix was autoapproved when it was landed; the security impact of this issue does not warrant a backmerge for this fix, so I am removing the auto-approval.

For VRP Panel: Attached is updated offscreen/hidden login PoC that uses local IDP for improved timing vs. Glitch-hosted IDP, which hopefully solves the reliability problems mentioned in #comment27. A proper remotely-hosted IDP should work similarly to the local IDP. (Again, the Glitch-hosted IDP doesn't always have realistic response times.)

The v2 PoC also uses a keypress for initial input, to avoid user having to switch between input devices. It also adds a debug mode to see the timing of the FedCM prompt more clearly on your device (in case it's still taking longer than expected).

As mentioned in #comment28, timing is only important between the first keypress and the first tab, and it's a minimum time threshold, not a maximum time threshold. This is because the FedCM prompt needs a few hundred milliseconds to fetch data from the IDP and then render the prompt. After the FedCM prompt renders, the remaining gestures can be made at any time with any amount of time between the gestures.

IMO, most users will be able to wait until the FedCM prompt renders, either because the website asks them to wait, or because they type at a slower speed than us (who are likely fast typers).

I verified this PoC on Windows 10 using snapshot build 1301615 [1] which is the closest build before patch [2].

REPRODUCTION CASE

(Almost identical to Scenario 2 from original report)

Setup:

1. Run a simulated IDP server: node server-single-account.js (attached in #comment32)

In real scenarios, an attacker would use a legit IDP since they would want real credentials.

Repro steps:

1. Navigate to https://alesandroortiz.com/security/chromium/fedcm-offscreen-v2.html
2. Press any key once.
3. When instructed, press tab twice, then press enter. Then wait a few seconds.

Observed: FedCM bubble is shown mostly off screen. User is able to interact with bubble. Attacker is able to obtain login token without user awareness.

Expected: FedCM bubble is shown on screen at all times, similar to permission prompt bubbles. If somehow offscreen, bubble is hidden or made non-interactive.

[1] https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Win_x64/1301615/

[2] https://chromium.googlesource.com/chromium/src/+/359cece04b0da05c40ce5ed9c5333df574069a7d

Attached server-single-account.js

Thank you for the new POC and additional information, Alesandro. Since the origin information was not made readily available to the user with the prompt off-window, we do agree there are security implications from this scenario. Due to the high gesture preconditions and low impact of this issue individually, we have instated this as a security bug, but a low severity one. Thanks again for taking the time to discover and report this and the other FedCM bugs you reported to us -- nice work!

Thanks for the reconsideration and reward!

To clarify, is the reward $1k for report + $1k bisect bonus, or was there no bisect bonus?

No worries, thanks for clarification!

This bug has been closed for more than 14 weeks. Removing issue access restrictions.