1875354 - (CVE-2024-7518) Fullscreen Spoof with Select Option showPicker()

Status: VERIFIED FIXED

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

Description

[Shaheen Fazim]

Attachment: poc.html

Recently, a bug 1832627 with a fix landing on Firefox nightly build 123.0a1 20240117092715 , was closed. I managed to bypass this fix by using the JavaScript showPicker() function with the select option.

In comparison to the previous method, this new approach requires only a single click from the user to spoof the screen fully. During the time of spoofing, the user cannot exit the picker or fullscreen with Esc, and can only escape after loading the spoofed page by removing the select option. If we could prolong this select option running indefinitely, trapping the user in fullscreen without escape using the above method would be possible as well.

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: 123.0a1 20240118095536, OS: Windows 11

Comment 1

[Shaheen Fazim]

Attachment: demo.mp4

Comment 2

[Shaheen Fazim]

This spoof only requires a single click from the user, and if the user tries to exit using the Esc key during the "connecting to Mozilla" phase, the exit from fullscreen won't work as well. (I think this is one of the best spoofs I've come up with; hope this report doesn't disappoint future-me.)

When tested (a slightly modified version made suitable for Chrome), the fullscreen notification is shown on top of the select option menu. I think we should also implement this, as it is a possible solution.

Comment 3

[Shaheen Fazim]

Attachment: chrome-122.png

Comment 4

[Tom Schuster]

I think we could also consider changing the showPicker code (and spec) to consume the transient user gesture activation, besides whatever fix we come up with for actually making ESC work...

Comment 5

[Oliver Medhurst [:canadahonk]]

Also mentioning Bug 1678389 which allows input file/color picker opening to consume a user activation if there is one.

Comment 6

[Tom Schuster]

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

I think we could also consider changing the showPicker code (and spec) to consume the transient user gesture activation, besides whatever fix we come up with for actually making ESC work...

Coming back to this. Chrome just suggested doing exactly this: https://github.com/whatwg/html/issues/10084. I think we should support this change and I would be willing to implement it.

Comment 7

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

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

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

I think we could also consider changing the showPicker code (and spec) to consume the transient user gesture activation, besides whatever fix we come up with for actually making ESC work...

Coming back to this. Chrome just suggested doing exactly this: https://github.com/whatwg/html/issues/10084. I think we should support this change and I would be willing to implement it.

We talked about this GH issue in our spec triage meeting yesterday. Yes, it looks reasonable.
Thanks Tom !

Comment 8

[Daniel Veditz [:dveditz]]

Other than what is being covered up, this seems the same as bug 1875354

Comment 9

[Shaheen Fazim]

Hi Daniel, this issue is not a typical fullscreen problem. The user cannot exit fullscreen during the transition, requiring less user interaction. Please reevaluate the severity. I notice bugs like a window popup or print function covering fullscreen a high-sec, and the previously fixed select option issue required 2 or 3 clicks, but this now only requires 1 click and has an extra method to prevent user escape. Kindly understand this bug and reevaluate the severity.

Comment 10

[Daniel Veditz [:dveditz]]

I'll re-rate this one for now, but we are re-evaluating the value of this kind of bug. Despite our worries about it we have not seen this kind of spoof exploit/social engineering used on people in the wild.

Comment 11

[Shaheen Fazim]

Friendly ping.

Comment 12

[Shaheen Fazim]

Hi, any updates on this issue? Can we assign someone to this issue for a fix.

Comment 13

[Andrew McCreight [:mccr8]]

This is waiting on some spec issues around user activation for pickers being addressed in bug 1877969.

Comment 14

[Andrew McCreight [:mccr8]]

I've CC'ed you on that bug so you can get a bit more visibility into what is happening. Unfortunately spec work across all browsers is a little slower to resolve than issues that just affect one browser.

Comment 15

[Oliver Medhurst [:canadahonk]]

Taking this as kind of UA bug

Comment 17

[Tom Schuster]

I would say this is still not fully fixed. The script is still able to infinitely open the <select> drop-down, because we unconditionally create a user activation when dismissing the dropdown: https://searchfox.org/mozilla-central/rev/2f48061aef8c8976b73749ee845e7b85751f5f2f/toolkit/actors/SelectChild.sys.mjs#262-269. I think we should not a create a user activation when nothing changed, just as we don't fire the input event in that case.

Comment 18

[Tom Schuster]

https://phabricator.services.mozilla.com/D214933

Comment 19

[Tom Schuster]

Attachment: Bug 1875354 - Don't create an unnecessary user activation from select when not firing the input event. r?edgar

Comment 20

[Oliver Medhurst [:canadahonk]]

Agree with Comment 17 (from my own findings after Bug 1877969 was landed)

Comment 21

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

Hi Tom, thank you for the WIPs. Do you plan to drive this bug through the completion line?

Comment 22

[Tom Schuster]

Sure, no problem.

Comment 23

[Tom Schuster]

Comment on attachment 9409650 [details]
Bug 1875354 - Don't create an unnecessary user activation from select when not firing the input event. r?edgar

Security Approval Request

• How easily could an exploit be constructed based on the patch?: Probably not that hard if you know what an user activation is.
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: Yes
• Which branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?: 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?: Easy for Beta/ESR128, a bit harder for ESR115
• How likely is this patch to cause regressions; how much testing does it need?: Relatively unlikely. Without the change even firing the user activation is just kind of randomly activated and not really usable without a setTimeout loop.
• Is the patch ready to land after security approval is given?: Yes
• Is Android affected?: Unknown

Comment 24

[Ryan VanderMeulen [:RyanVM]]

Sounds like we're going to want a rebased patch for ESR115 also based on comment 23.

Comment 25

[Tom Schuster]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #24)

Sounds like we're going to want a rebased patch for ESR115 also based on comment 23.

Without bug 1877969 I don't think there is much of a point trying to uplift this.

Comment 26

[Ryan VanderMeulen [:RyanVM]]

(In reply to Tom Schuster (MoCo) [mostly OOO] from comment #25)

Without bug 1877969 I don't think there is much of a point trying to uplift this.

Bit of a tough quandary with this being rated sec-high at the moment. Given the comment about ESR115 in comment 23, is the severity actually that high for that branch?

Comment 27

[Tom Schuster]

Oh wait, never mind. HTMLSelectElement showPicker does not even exist in ESR115, because bug 1854112 landed in 121.

Comment 29

[Daniel Veditz [:dveditz]]

Comment on attachment 9409650 [details]
Bug 1875354 - Don't create an unnecessary user activation from select when not firing the input event. r?edgar

sec-approval+ = dveditz

Comment 30

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0d0b5ef1231f
Don't create an unnecessary user activation from select when not firing the input event. r=edgar

Comment 31

[Frederik Braun [:freddy]]

(In reply to Tom Schuster (MoCo) [mostly OOO] from comment #27)

Oh wait, never mind. HTMLSelectElement showPicker does not even exist in ESR115, because bug 1854112 landed in 121.

Tom is out of office. Can you help confirm that ESR is unaffected?

Comment 32

[Oliver Medhurst [:canadahonk]]

I agree ESR is unaffected.

Comment 33

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

https://hg.mozilla.org/mozilla-central/rev/0d0b5ef1231f

Comment 34

[BugBot [:suhaib / :marco]]

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

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

For more information, please visit BugBot documentation.

Comment 35

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

:tschuster is OOO.
Forwarding the needinfo request from comment 34 to Oliver.

Comment 36

[Oliver Medhurst [:canadahonk]]

Attachment: Bug 1875354 - Don't create an unnecessary user activation from select when not firing the input event. r?edgar

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

Comment 37

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: Site spoofing security risk
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: n/a
• Risk associated with taking this patch: Low
• Explanation of risk level: Changes how select element user activation works so could break sites but nothing reported
• String changes made/needed: n/a
• Is Android affected?: no

Comment 38

[Donal Meehan [:dmeehan]]

This will also need an esr128 uplift request

Comment 39

[Oliver Medhurst [:canadahonk]]

Attachment: Bug 1875354 - Don't create an unnecessary user activation from select when not firing the input event. r?edgar

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

Comment 40

[Phabricator Automation]

esr128 Uplift Approval Request

• User impact if declined: Site spoofing security risk
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: n/a
• Risk associated with taking this patch: Low
• Explanation of risk level: Changes how select element user activation works so could break sites but nothing reported
• String changes made/needed: n/a
• Is Android affected?: no

Comment 41

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/95977c27ca91

Comment 42

[Shaheen Fazim]

Thank you for the fix and bounty.

Comment 43

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/0fb6c5d5981a

Comment 44

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Attachment: fullscreen.gif

Reproduced the issue with Firefox 129.0a1 (2024-07-03) and 128.0 on Windows 10x64 using the attached test case. After clicking the Click Me button, the "Connecting to Mozilla account" transition cannot be closed by pressing the Esc key until the login page is displayed.

The issue is verified fixed with Firefox 130.0a1 (2024-07-18), 129.0b5, and 128.1esr from comment 43 on Windows 10x64, macOS 12 and Ubuntu 23.10. The "Connecting to Mozilla account" transition can be closed successfully by pressing the Esc key.

However, I saw two distinct behaviors between Firefox and Chrome that I need to make sure are expected:

1. After clicking the click me button Firefox does not enter full screen and will only display a window where the "Connecting to Mozilla account" message is displayed.
2. The Username and Password fields from the sign-in page are not editable and clicking them will enter fullscreen.
   Are these behaviors expected? Attached a screen recording from a fixed build. Thank you in advance!

Comment 45

[Shaheen Fazim]

Attachment: poc-update.html

(In reply to Alexandru Trif, Desktop QA [:atrif] from comment #44)

2. The Username and Password fields from the sign-in page are not editable and clicking them will enter fullscreen.
   Are these behaviors expected? Attached a screen recording from a fixed build. Thank you in advance!

Thank you for testing. My proof of concept (PoC) was outdated because the image inisde the code <img src="https://fazim-pentest.000webhostapp.com/about/top.png" class="header" /> no longer exists,which is creating an overlay case on top of the input, preventing it from being focused. However, removing this image code would reproduce the issue without any change in the proof of concept. I have updated the proof of concept by removing the nonexistent image code block so that the input works as normal.

Comment 46

[Shaheen Fazim]

Attachment: test-input.mp4

Here is the video testing the input.

Regarding the behavior where clicking will enter fullscreen mode, my proof of concept code listens to all click events, so any click will activate fullscreen mode, which is the expected behavior.

document.addEventListener('click', function (event) {
    document.documentElement.requestFullscreen();
    setTimeout(function () {
    ...
    });
});

Comment 47

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Thank you for testing. My proof of concept (PoC) was outdated because the image inisde the code <img src="https://fazim-pentest.000webhostapp.com/about/top.png" class="header" /> no longer exists,which is creating an overlay case on top of the input, preventing it from being focused

Regarding the behavior where clicking will enter fullscreen mode, my proof of concept code listens to all click events, so any click will activate fullscreen mode, which is the expected behavior.

Thank you very much for the detailed response and updated test case. I can confirm that the fields are editable now.

However, I saw two distinct behaviors between Firefox and Chrome that I need to make sure are expected:

1. After clicking the click me button Firefox does not enter full screen and will only display a window where the "Connecting to Mozilla account" message is displayed.

Leaving the ni? because I'm not sure about the above behavior. Firefox does not enter fullscreen on the first click when clicking the Click Me! message. I don't know if this is expected.
Since Tom is out of the office, can you please confirm if the above behavior is expected, Oliver? Thank you in advance!

Comment 48

[Oliver Medhurst [:canadahonk]]

I believe that is expected (due to lack of user activation) and should be fine.

Comment 49

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Thank you! Closing this as verified based on the above comments.

Comment 52

[Tyson Smith [:tsmith]]

Attachment: advisory.txt