1860065 - (CVE-2024-1550) Cursor mouse move automatically after fullscreen mode (using requestPointerLock()) lead to clickjacking

Status: VERIFIED FIXED

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

Description

[Hafiizh]

Attachment: bandicam 2023-10-19 20-55-22-457.mp4

i found vulnerability where Cursor mouse move automatically after fullscreen mode lead to spoof (it allow permission)

1. open new.html
   2.,click open button
2. after popup shown click once on 3-5 click button until popup window shown , then click 3-5 times

OS: Windows 10
119.0b9 (64-bit)

Comment 1

[Hafiizh]

Attachment: new.html

Comment 2

[Hafiizh]

Attachment: lock2-5.html

Comment 3

[Hafiizh]

Attachment: permissionshow.html

Comment 4

[Hafiizh]

Attachment: mos.jpg

Comment 5

[Hafiizh]

Hello any updates?

Comment 6

[:Gijs (he/him)]

I don't understand the "spoof" in the summary. The URL bar is visible and shows the right things, as far as I can tell?

ISTM the think this is about is clickjacking because requestPointerLock moves the mouse. Is that right?

Comment 7

[Hafiizh]

Yes, it's true that this is clickjacking because the mouse cursor moves automatically after fullscreen mode

Comment 8

[Andrew McCreight [:mccr8]]

I think this should be an S2. It does require some specific user interaction, but the results are rather bad. We should at least figure out how hard it is to fix.

Comment 9

[Hafiizh]

Attachment: lock2-5_new.html

Comment 10

[Hafiizh]

i created simple poc

Comment 11

[Hafiizh]

Attachment: bandicam 2023-11-03 20-40-41-123.mp4

Comment 12

[Hafiizh]

Attachment: bandicam 2023-11-03 20-40-41-123_muted.mp4

Comment 13

[Hafiizh]

POC:

1. open lock2-5_new.html
2. click fastly on the button 3-6 times

Comment 14

[Hafiizh]

I don't understand why this bug is given sec-moderate while my other report with something similar like this is given sec-high (https://bugzilla.mozilla.org/show_bug.cgi?id=1857430)

Comment 15

[Daniel Veditz [:dveditz]]

They are both in the mushy borderline of potentially high impact vs requiring too much victim participation. "click here to win a prize" exploits are a true sec-high. "play my game" exploits will have high impact, but only on a limited number of victims because no one's got time for games like that. If you've got the skills to make a compelling enough game you would make more legit money on games than scamming people for camera permission.

As a result the ratings in this zone depend a lot on the people in the room when we triage and probably our mood. Today when I look at these two bugs again I might call this one sec-high as more convincing, and the other bug sec-moderate. But they're obviously related. Depending on how bug 1857430 is fixed that might make this bug even less convincing, because in part you're taking advantage of the same "button-enable timer is already running during the transition" effect.

Bug bounties for highest-moderate and lowest-high are in the same range, if that's your concern. I'll raise this one for now, but we need to reevaluate when we know how much the fix for one affects the other.

Comment 16

[Andrew McCreight [:mccr8]]

Bug 1863083 is about using moveTo to trick the user into clicking on a permission dialogue which is kind of in the same general ballpark.

Comment 17

[Andrew McCreight [:mccr8]]

Paul, is this something that should be dealt with in the permissions code like bug 1857430? If so, we can move it over there. Thanks.

Comment 18

[Emma Zühlcke [:emz]]

Isn't the bug here rather that pointerlock changes the mouse position? Bug 1857430 doesn't address the mouse move issue. It does however make the issue less severe by making sure the button isn't clickable for longer.

Comment 19

[Andrew McCreight [:mccr8]]

I don't know what the bug is, that's why I was asking. Thanks, I'll leave it here then.

Comment 20

[Edgar Chen [:edgar]]

When pointer lock is requested, we store the mouse position and attempt to reset the mouse to the same position after pointer lock is released. These actions are all handled in content process, but content process might not always know the precise position of the mouse, e.g. mouse is not on the web content, but somewhere else. In such case, mouse is reset to top-left of content after pointer lock. We probably should handle that in parent process, rather than content process.

Comment 21

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

Edgar, assigning this to you since you've been investigating this and exploring the best solution.

Comment 22

[Edgar Chen [:edgar]]

The fix might require two things,

• Lock pointer to <xul browser> also in parent process when content requests pointer lock.
• Handle reset-pointer-to-central in parent process (now it is handled in content process).

Comment 23

[Edgar Chen [:edgar]]

Bug 1255338 is a more generic change which should also fix this.

Comment 24

[Edgar Chen [:edgar]]

When I am working on bug 1255338, I found there is a simpler patch that can improve this bug, though it doesn't fully fix the underlying issue, but the patch is simpler and can be uplifted safely. The full fix will still be handled in bug 1255338.

Comment 25

[Hafiizh]

Can security bugs depend on non-security bugs?

Comment 26

[Edgar Chen [:edgar]]

Attachment: Bug 1860065 - Use sLastScreenPoint to restore mouse position after releasing pointer lock; r?smaug

Comment 27

[Andrew McCreight [:mccr8]]

(In reply to Hafiizh from comment #25)

Can security bugs depend on non-security bugs?

Yes, that's fine. The dependence is hidden from people who don't have security access. The main issue is ensuring that the patch gets uplifted everywhere that is appropriate, but that can usually be tracked in the security bug.

Comment 28

[Edgar Chen [:edgar]]

Comment on attachment 9368856 [details]
Bug 1860065 - Use sLastScreenPoint to restore mouse position after releasing pointer lock; r?smaug

Security Approval Request

• How easily could an exploit be constructed based on the patch?: It may not be difficult; the patch indicates that the problem is related to the mouse position resetting after exiting pointer lock.
• 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?: Yes
• If not, how different, hard to create, and risky will they be?: The patch should be applied without too much conflicts.
• How likely is this patch to cause regressions; how much testing does it need?: It should be safe; the change is not complicated.
• Is Android affected?: Yes

Comment 29

[Tom Ritter [:tjr]]

Comment on attachment 9368856 [details]
Bug 1860065 - Use sLastScreenPoint to restore mouse position after releasing pointer lock; r?smaug

Approved to land and uplift if desired

Comment 30

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4a6dd45b089b
Use sLastScreenPoint to restore mouse position after releasing pointer lock; r=smaug

Comment 31

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

https://hg.mozilla.org/mozilla-central/rev/4a6dd45b089b

Comment 32

[Edgar Chen [:edgar]]

Attachment: Bug 1860065 - Use sLastScreenPoint to restore mouse position after releasing pointer lock; r?smaug

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

Comment 33

[Phabricator Automation]

Uplift Approval Request

• String changes made/needed: None
• Risk associated with taking this patch: Low
• Explanation of risk level: Using last screen pointer to restore the mouse position is pretty straightforward
• User impact if declined: Cursor mouse might move automatically after releasing pointer lock and lead to clickjacking
• Steps to reproduce for manual QE testing: Use the test script in https://bugzilla.mozilla.org/show_bug.cgi?id=1860065#c13
• Code covered by automated testing: no
• Is Android affected?: yes
• Fix verified in Nightly: yes
• Needs manual QE test: yes

Comment 34

[Pascal Chevrel:pascalc]

We also need a patch and uplift request for the ESR115 branch if all branches are affected, thanks.

Comment 35

[Edgar Chen [:edgar]]

(In reply to Pascal Chevrel:pascalc from comment #34)

We also need a patch and uplift request for the ESR115 branch if all branches are affected, thanks.

I will prepare a patch for ESR115. Thanks!

Comment 36

[Edgar Chen [:edgar]]

Attachment: Bug 1860065 - Use sLastScreenPoint to restore mouse position after releasing pointer lock; r?smaug

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

Comment 37

[Vlad Lucaci, Thunderbird QA (:vlucaci)]

I have reproduced this issue on Win 11 x64 using STR from comment 0 and comment 13, on an affected Nightly build (2023-10-18).

Confirming this issue as verified fixed on 124.0a1(20240130045011) using Windows 11, Ubuntu 22 and macOS 14.

Comment 38

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/badb0c014722

Comment 39

[Edgar Chen [:edgar]]

Attachment: Bug 1860065 - Use sLastScreenPoint to restore mouse position after releasing pointer lock;

Comment 40

[Phabricator Automation]

Uplift Approval Request

• User impact if declined: Cursor mouse might move automatically after releasing pointer lock and lead to clickjacking
• Fix verified in Nightly: yes
• Steps to reproduce for manual QE testing: Use the test script in https://bugzilla.mozilla.org/show_bug.cgi?id=1860065#c13
• Risk associated with taking this patch: Low
• Needs manual QE test: yes
• Explanation of risk level: Using last screen pointer to restore the mouse position is pretty straightforward
• String changes made/needed: None
• Is Android affected?: yes
• Code covered by automated testing: no

Comment 41

[Vlad Lucaci, Thunderbird QA (:vlucaci)]

Confirming this issue as verified fixed on 123.0b4(20240129091730) using Windows 11, Ubuntu 22 and macOS 14.

Comment 42

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/8c0d9a15ca94

Comment 43

[Vlad Lucaci, Thunderbird QA (:vlucaci)]

Confirming this issue as verified fixed on 115.8.0esr(20240212204114) using Windows 11, Ubuntu 22 and macOS 14.

Comment 44

[Tom Ritter [:tjr]]

Attachment: advisory.txt