1909535 - (CVE-2024-11692) Show Select Option on any Website

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Shaheen Fazim]

Attachment: poc.html

Bug 1875824 was not properly fixed by Bug 1877969, and there is a workaround. A malicious website could use other methods, such as onmousedown, to bypass the security measures.

Steps to Reproduce:

1. Download the poc.html file.
2. Open the poc.html file in firefox for testing.

Tested on latest Nightly build version: 130.0a1 (2024-07-23) (64-bit), OS: Windows 11

Comment 1

[Shaheen Fazim]

Attachment: demo.mp4

Video demo.

Comment 2

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

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

For more information, please visit BugBot documentation.

Comment 3

[:Gijs (he/him)]

Is this addressed by bug 1909163 and bug 1907032?

Comment 4

[:Gijs (he/him)]

Looks like my fix in bug 1909163 is incomplete, for starters...

Comment 5

[:Gijs (he/him)]

Is this addressed at this point, in the latest beta builds? I expect so...

Comment 6

[Shaheen Fazim]

Attachment: demo.mp4

Just tested on the latest beta build; the bug still exists.

Comment 7

[Tom Schuster (MoCo)]

I can actually still reproduce this issue as well. However sometimes the POC now fails for me. It seems like it only shows the popup on google the first time after reloading.

Comment 8

[:Gijs (he/him)]

(In reply to Tom Schuster (MoCo) from comment #7)

I can actually still reproduce this issue as well. However sometimes the POC now fails for me. It seems like it only shows the popup on google the first time after reloading.

There's a race of some kind. Also, beta 8 does not yet have the patch from bug 1907032. But it seems like on Nightly in this case we fire onLocationChange before we open the select (at least on my machine), and then presumably when the select opens we also still haven't made the BC fully background so it also passes the checks from 1907032.

What I don't understand is why the user activation bits don't stop this - I would have expected the window.open to consume user activation for the mousedown and thus click, and then to just not bother opening the popup at all. Why does that part not work?

Comment 9

[Shaheen Fazim]

Yes, I get the same behavior too. The select option only shows the first time, and we need to reload the page to see it again.
I also tested the other bug, Bug 1909529, and it has been addressed, but this one is still present in the latest beta version.

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

What I don't understand is why the user activation bits don't stop this - I would have expected the window.open to consume user activation for the mousedown and thus click, and then to just not bother opening the popup at all. Why does that part not work?

Is mousedown not considered for consuming user activation?

Comment 10

[:Gijs (he/him)]

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

(In reply to Tom Schuster (MoCo) from comment #7)

I can actually still reproduce this issue as well. However sometimes the POC now fails for me. It seems like it only shows the popup on google the first time after reloading.

There's a race of some kind. Also, beta 8 does not yet have the patch from bug 1907032. But it seems like on Nightly in this case we fire onLocationChange before we open the select (at least on my machine), and then presumably when the select opens we also still haven't made the BC fully background so it also passes the checks from 1907032.

What I don't understand is why the user activation bits don't stop this - I would have expected the window.open to consume user activation for the mousedown and thus click, and then to just not bother opening the popup at all. Why does that part not work?

A bunch of people have moved on... at a guess, Masayuki, can you take a look at why this particular poc still reproduces in some cases?

Comment 11

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

Well, showing the popup is handled as a default action of mousedown. That runs after the onmousedown which opens another tab. I don't know whether window.open is handled synchronously or asynchronously. Anyway, the internal event handler requests that to parent process synchronously and update the state in content process immediately. As far as I've checked, mElement->OwnerDoc()->IsVisible() returns true even when this bug is reproduced at HTMLSelectEventListener::MouseDown. And also, it seems that mElement is not focused at the method. So, could be focus and blur may be canceled by changing the tab in some conditions?

Comment 12

[:Gijs (he/him)]

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

Well, showing the popup is handled as a default action of mousedown. That runs after the onmousedown which opens another tab. I don't know whether window.open is handled synchronously or asynchronously.

So can/should we check for user activation having already been consumed in this internal handler, and would that fix things? (ie does window.open consume user activation synchronously in the child process)

I'm also not sure I understand why we consume user activation when calling showPicker but not when the user just clicks the item.

Comment 13

[Nika Layzell [:nika] (ooo, ni? for response)]

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

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

Well, showing the popup is handled as a default action of mousedown. That runs after the onmousedown which opens another tab. I don't know whether window.open is handled synchronously or asynchronously.

So can/should we check for user activation having already been consumed in this internal handler, and would that fix things? (ie does window.open consume user activation synchronously in the child process)

Window opening / pop-up blocking code is quite old, so it doesn't surprise me too much if it doesn't interact as expected with the modern user activation logic. I unfortunately am not super familiar with the expected behaviour here but I do worry about changing how activation interacts with window opening could have webcompat risks.

Based on https://searchfox.org/mozilla-central/rev/1b90936792b2c71ef931cb1b8d6baff9d825592e/docshell/base/BrowsingContext.cpp#2231, it looks like sometimes popup abuse level can consume user interaction, but perhaps not reliably? It also wouldn't surprise me too much if this is bypassed for link click default handlers at least sometimes.

Comment 14

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

Unfortunately, I'm not familiar with user activation too and I got lost now. I was thinking that the better behavior is that the dropdown should be closed when switched to the new tab. So, I was thinking that if the tab switch occurs during opening the dropdown, the dropdown should be closed immediately.

Comment 15

[Tom Schuster (MoCo)]

(I will try to give this another look next week)

Comment 16

[:Gijs (he/him)]

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

Unfortunately, I'm not familiar with user activation too and I got lost now. I was thinking that the better behavior is that the dropdown should be closed when switched to the new tab. So, I was thinking that if the tab switch occurs during opening the dropdown, the dropdown should be closed immediately.

Yes, that should also happen - but it would appear there is a race between when we check if the tab for which the dropdown is being opened is in the background, and when we try to close open popups when switching tabs.

Comment 17

[Tom Schuster (MoCo)]

Apparently even when the dropdown is hidden successfully, this doesn't actually involve tabspecific at all. To be fair, it probably wouldn't work anyway, because SelectParentHelper.open seems to happen after XULBrowserWindow.onLocationChange. The reason the popup is closed at least sometimes, is actually the Forms:BlurDropDown-Pong message handler.

Comment 18

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Olli is currently changing some pop-up blocking behavior, and plans to enable https://bugzilla.mozilla.org/show_bug.cgi?id=1911736 soon. Not quite sure how relevant his work relates here though. Adding him to the CC list and see if he has other things to add.

Comment 19

[Edgar Chen [:edgar]]

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

I'm also not sure I understand why we consume user activation when calling showPicker but not when the user just clicks the item.

The spec does not clearly define the behavior when the user clicks on the <select> element. And other browsers do not check or consume the user activation in this case, either. I worry that changing this might cause web-compatibility problem unless other browsers adopt the same behavior. I file https://github.com/whatwg/html/issues/10701.

Checking the user activation can address this case, but we still have a race problem if SelectParentHelper.open is triggered after we attempt to close open popups while switching tabs in other possible scenarios. Fixing the race on select popup seems the proper solution to me.

Comment 20

[Edgar Chen [:edgar]]

Attachment: Bug 1909535 - Don't show select dropdown in background tabs; r?emilio

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f8116bec30a3
Don't show select dropdown in background tabs; r=emilio

Comment 22

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

Backed out for causing dt & bc failures @ browser_html_options_ui.js / browser_webextension_dropdown.js

Backout link: https://hg.mozilla.org/integration/autoland/rev/df405c12e68e5b31c08e237aeb0a50fcf28590b1
Push with failures
Failure log -> toolkit/mozapps/extensions/test/browser/browser_html_options_ui.js | Test timed out
Failure log ->browser_webextension_dropdown

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/dc7dd3bca766
Don't show select dropdown in background tabs; r=emilio

Comment 24

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

https://hg.mozilla.org/mozilla-central/rev/dc7dd3bca766

Comment 25

[Donal Meehan [:dmeehan]]

:edgar could you add beta and esr128 uplift requests on this?
It grafts cleanly for both

Comment 26

[Edgar Chen [:edgar]]

Attachment: Bug 1909535 - Don't show select dropdown in background tabs; r?emilio

Original Revision: https://phabricator.services.mozilla.com/D225706

Comment 27

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: The selection dropdown can appear from a background tab, which might confuse the user
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: follow the STR in https://bugzilla.mozilla.org/show_bug.cgi?id=1909535#c0
• Risk associated with taking this patch: Low
• Explanation of risk level: The patch disallows opening a selection dropdown from an inactive window or tab, so it should be safe.
• String changes made/needed: None
• Is Android affected?: no

Comment 28

[Edgar Chen [:edgar]]

Attachment: Bug 1909535 - Don't show select dropdown in background tabs; r?emilio

Original Revision: https://phabricator.services.mozilla.com/D225706

Comment 29

[Phabricator Automation]

esr128 Uplift Approval Request

• User impact if declined: The selection dropdown can appear from a background tab, which might confuse the user
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: follow the STR in https://bugzilla.mozilla.org/show_bug.cgi?id=1909535#c0
• Risk associated with taking this patch: Low
• Explanation of risk level: The patch disallows opening a selection dropdown from an inactive window or tab, so it should be safe.
• String changes made/needed: None
• Is Android affected?: no

Comment 30

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/590803c04a43

Comment 31

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/a6cf1a7cd289

Comment 32

[Raluca Popovici, Desktop QA]

I was able to reproduce this issue on Nightly 130.oa1(2024-07-23)(64 bit) using Windows 10x64.
The bug is verified as fixed(select dropdown is not displayed in background tabs) on Nightly 134.0a1(2024-11-04), Fx Beta 133.0b4(treeherder build) and Fx esr 128.5.0(treeherder build) using Windows 10x64, Windows 11, MacOS 13.2.1 and Ubuntu 24.10.

Comment 33

[Daniel Veditz [:dveditz]]

We downgraded the severity of bug 1909529 to sec-low because that PoC only worked if people disabled the popup blocker. This version of the spoof showed it was possible to work around that restriction, but the spoofing capabilities are still pretty low.

Comment 34

[Tom Ritter [:tjr] (OOTO until 7/21)]

Attachment: advisory.txt