1826622 - (CVE-2023-32212) datalist option can hide url address bar lead to spoof

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Hafiizh]

Attachment: spooffirefox.html

I found a vulnerability on firefox 110.0.1 (64-bit) (i tested on windows OS) where datalist option can cover url address bar which can lead to spoofs.

step to reproduces:

1. open http://103.186.0.20/datalist.html or spooffirefox.html
2. press "h" then the option of datalist cover url address bar

Comment 1

[Hafiizh]

Attachment: bandicam 2023-04-06 00-36-01-473.mp4

Comment 2

[Andrew McCreight [:mccr8]]

I could reproduce the issue as reported.

Clicking on the page or hitting at least some keys clears the stuff covering the URL bar, which also mitigates it a bit.

Comment 3

[Andrew McCreight [:mccr8]]

(I'm on an up-to-date 113 Nightly.)

Comment 4

[Andrew McCreight [:mccr8]]

On second thought, looking at the test case it has things like style="margin-top: -50px so I suspect that this is more of a CSS issue than a DOM issue.

Comment 5

[Andrew McCreight [:mccr8]]

The test case shows http not https, but of course it would be easy to change the text. You could even get fancy and do
🛡️🔒 https://www.google.com/

but at least on my system the shield and lock are colored which probably makes it less convincing not more.

Comment 6

[Daniel Veditz [:dveditz]]

On my system the text is in dark mode (like my system) but my browser theme is light so it doesn't match. It also wildly mismatches the size and placement of my url bar so that really sticks out. Probably could do better detection to make a better spoof.

But it doesn't appear you can do anything with the "fake google". If you type or click the spoof goes away, so you'd get maybe one misdirected click?

This particular instance of spoofing I'd rate a "low", but I'm concerned that apparently the "(floating) option allowed to extend outside of content boundary" problem is back or was not fixed correctly in the past and there's likely more mischief you can do with this. For example, use an option to cover up a permission prompt that bleeds into the content area (one type of spoof reported several times in the past)

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

It seems that popups should be opened at most the content area to avoid overlapping with any chrome UI. I don't know about the sidebar though. On the other hand, overflowing from bottom edge could be reasonable because adjusting the position moves up could cause odd visual if there is enough space bottom of the window.

Comment 8

[Daniel Holbert [:dholbert]]

(In reply to Andrew McCreight [:mccr8] from comment #4)

On second thought, looking at the test case it has things like style="margin-top: -50px so I suspect that this is more of a CSS issue than a DOM issue.

I don't think there's any specific CSS issue here; that margin-top is just changing the position of the input element.

We anchor the datalist autocomplete-popup-menu to its spawning-element's position, and it seems that "works" even if the element is offscreen, as happens to be the case here. That's maybe worth avoiding, as Masayuki suggests.

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(still sick) from comment #7)

It seems that popups should be opened at most the content area to avoid overlapping with any chrome UI.

Agreed. FWIW it seems like we do seem to have a version of this constraint for <select> menu-popups (slightly different from the pOC here), under some configurations -- specifically for Wayland-disabled Linux environments (may require environmental variable MOZ_ENABLE_WAYLAND=0 if you have Wayland as your window manager). In constrast: if I have Wayland enabled, then the select menu popup can similarly overlap the Firefox UI (and even extend outside the window on both sides).

(The datalist autocomplete-popups seem to be allowed to escape the content area & overlap Firefox UI regardless of whether Wayland is enabled.)

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (simple offscreen-anchored datalist popup)

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: testcase 3 (non-problematic -- now with on-screen datalist-backed input, for comparison)

Here's a variant of testcase 2 just to experiment with how datalist-completion-popup normally renders for an on-screen input.

It looks like Firefox lets this run off the bottom of the window, while Chrome constrains it to the content area (to the point of not showing a popup at all if your window is sufficiently short).

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: testcase 4 (now using 'select')

Here's an example with select instead of datalist-backed-input. As noted in comment 8, in wayland-disabled Linux (at least), we seem to constrain the select popup to the content area here.

Comment 12

[Daniel Holbert [:dholbert]]

Attachment: testcase 5 (hosting testcase 2 in a same-origin iframe)

Comment 13

[Daniel Holbert [:dholbert]]

Attachment: testcase 5 (with input inside of an iframe)

Comment 14

[Daniel Holbert [:dholbert]]

RE how-much-to-constrain autocomplete-popups -- testcase 5 is an example to test whether these datalist autocomplete-popups might be constrained to the iframe viewport (more restrictive) vs. the top-level viewport (less restrictive). Chrome seems to choose the less-restrictive of these options; it constrains them to the top-level viewport. Firefox doesn't constrain them at all.

Two other notes:

• on macOS (probably Windows too?), Firefox does seem to constrain <select> popups (in testcase 4) to the content area. I suspect that that's our intent, and that the Wayland-specific escaping that I noted is just an bug/special-case that we have with Wayland.
• I tested Safari on macOS, and it seems to be "permissive" in all cases here, FWIW; they'll gladly let all of these popups (including select) escape the content area and overlap the browser UI (or stick off the bottom of the browser window).

Comment 15

[Daniel Holbert [:dholbert]]

(Restoring needinfo=emilio open since I think he's looked at dropdown-menu-popup sizing & positioning in recent years, and would probably still be in a great position to investigate/mitigate here, if he's got cycles.)

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

it doesn't appear you can do anything with the "fake google". If you type or click the spoof goes away, so you'd get maybe one misdirected click?

devil's advocate: I imagine the attacker would be hoping that the user might just glance at the URLbar at first (while the spoof is up) to visually "confirm" that they're really looking at a Google login page, and then the user would proceed to click into a password field and type in their credentials (not noticing that the spoof went away). Probably a long-shot, but could conceivably fool some users in some cases.

Comment 16

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1826622 - [wayland] Ensure explicit popup constraints are honored. r=stransky

This makes sure that wayland <select> elements are constrained to the
window.

Comment 17

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1826622 - Constrain autocomplete popup like select. r=Gijs!,sgalich!

Depends on D175039

Comment 18

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

Constrain autocomplete popup like select. r=Gijs,sgalich
https://hg.mozilla.org/integration/autoland/rev/b6fe0412464bfe0dd3aab0d6820448fed004fff3
https://hg.mozilla.org/mozilla-central/rev/b6fe0412464b

Comment 19

[Emilio Cobos Álvarez (:emilio)]

Reopening to:

• Land the wayland fix.
• Do the form validation popups as Gijs suggested.

Comment 20

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1826622 - Constrain form validation popups. r=Gijs

Comment 21

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

Constrain form validation popups. r=Gijs
https://hg.mozilla.org/integration/autoland/rev/9ed92b735a38f0743ca6767e1548a2dae28c48a6
https://hg.mozilla.org/mozilla-central/rev/9ed92b735a38

Comment 22

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

[wayland] Ensure explicit popup constraints are honored. r=stransky
https://hg.mozilla.org/integration/autoland/rev/421fca90ff1272ab8bdb4965728833bc22eed3d7
https://hg.mozilla.org/mozilla-central/rev/421fca90ff12

Comment 23

[Ryan VanderMeulen [:RyanVM]]

This grafts cleanly to Beta - please nominate for uplift when you get a chance. Is ESR also affected? If so, it'll need rebased patches.

Comment 24

[Emilio Cobos Álvarez (:emilio)]

Comment on attachment 9327766 [details]
Bug 1826622 - [wayland] Ensure explicit popup constraints are honored. r=stransky

Beta/Release Uplift Approval Request

• User impact if declined: comment 0
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: comment 0
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Patches are relatively straight-forward.
• String changes made/needed: none
• Is Android affected?: No

Comment 25

[Emilio Cobos Álvarez (:emilio)]

Do we need to uplift this to ESR given it's sec-moderate?

Comment 26

[Ryan VanderMeulen [:RyanVM]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #25)

Do we need to uplift this to ESR given it's sec-moderate?

If it's practical to do so, yes. If it's too risky or difficult of a rebase, there's flexibility.

Comment 27

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9327766 [details]
Bug 1826622 - [wayland] Ensure explicit popup constraints are honored. r=stransky

Approved for 113.0b5.

Comment 28

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/f40cf9027623
https://hg.mozilla.org/releases/mozilla-beta/rev/1495a1db3506
https://hg.mozilla.org/releases/mozilla-beta/rev/d88656f69ef3

Comment 29

[Emilio Cobos Álvarez (:emilio)]

Can we get https://hg.mozilla.org/releases/mozilla-beta/rev/d88656f69ef3 backed out from beta for causing bug 1828772? The wayland set-up needs a bit more work.

Comment 30

[Ryan VanderMeulen [:RyanVM]]

Backed out the Wayland patch for 113.0b6 for causing bug 1828772 per Emilio's request. We will let that change and any follow-up fixes from other bugs ride the trains to release.
https://hg.mozilla.org/releases/mozilla-beta/rev/00880b627650

Comment 31

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Reproducible on a 2023-04-11 Nightly build on Windows 10.
Verified as fixed on Firefox 113.0b6(build ID: 20230420180037) and Nightly 114.0a1(build ID: 20230420212414) on Windows 10 and macOS 12.
Datalist tooltip no longer covers the urlbar.
Verified as fixed on Nightly 114.0a1(build ID: 20230420212414) on Ubuntu 22. Have yet to verify the fix on beta-channel once the patch lands.

Comment 34

[Daniel Veditz [:dveditz]]

This also resolves bug 1753339 and bug 1753341 so ESR 102 should also get this patch.

Comment 35

[Emilio Cobos Álvarez (:emilio)]

Attachment: ESR102 patch.

ESR Approval Request Comment
[Feature/Bug causing the regression]: N/A
[User impact if declined]: comment 0
[Is this code covered by automated tests?]: no
[Has the fix been verified in Nightly?]: yes
[Needs manual test from QE? If yes, steps to reproduce]: comment 0
[List of other uplifts needed for the feature/fix]: This includes bug 1709027, and doesn't include the Wayland patch.
[Is the change risky?]: not much
[Why is the change risky/not risky?]: The patch is rather simple.
[String changes made/needed]: none

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

Comment 36

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9330140 [details] [diff] [review]
ESR102 patch.

Thanks for the roll-up patch. Approved for 102.11esr.

Comment 37

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr102/rev/5aa1b21bd42f

Comment 38

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Reproducible on a 2023-04-11 Nightly build on macOS 12.
Verified as fixed on Firefox 102.11.0esr(build ID: 20230501163504) on Windows 10, Ubuntu 22 and macOS 12.
Datalist tooltip no longer covers the urlbar.

Comment 39

[Tyson Smith [:tsmith]]

Attachment: advisory.txt