1694513 - (CVE-2024-6607) Force PointerLock to Remain on Locked State even "escape" Key Pressed (able to trick user to press another combination to escape)

Status: RESOLVED FIXED

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

Description

[Irvan Kurniawan [:sourc7]]

Attachment: pointerlock+validitymessage.html

By setting CSS property to display then create a Blob canvas object, afterward set the callback parameter to element.onselectstart to call theelement.requestPointerLock() function, when user double-click the element the cursor will remain locked on the target element even if the user presses the "escape" key (default unlock gesture) to unlock the pointer.

I also found that it is possible to overlap the Firefox WebExtension install dialog or permission request dialog using the select element custom validity message.

Therefore when user unable to unlock the pointer, the attacker can show spoof message "Press Alt+A" to unlock the pointer, after user presses the combination key, the pointer will unlocked and user also unconsciously pressed combination key to allow the extension install or permission request.

Version affected:

• Firefox Nightly 88.0a1 (2021-02-23) (64-bit)
• Firefox Release 86.0 (64-bit)
• Firefox ESR 78.8.0esr (64-bit)

Steps to Reproduce:

1. Visit attached pointerlock+validitymessage.html
2. Double click the instruction text
3. Press "escape" key repeatedly to test whether user able to unlock the pointer
4. After ~4s permission request dialog will appear, afterward the select custom validity message will also appear to overlap the dialog
5. Press "Alt+A" to take back control
6. Notification permission are allowed and the pointer is now unlocked

Comment 1

[Irvan Kurniawan [:sourc7]]

Attachment: Firefox - PointerLock Remain on Locked State + Overlap Spoof Message.mp4

Comment 2

[Daniel Veditz [:dveditz]]

There's at least two issues here:

1. Malicious page should not be able to draw ANYTHING on top of our doorhangers
2. Malicious page should not be able to keep you in pointerlock

We need to spin out a bug for one of those because those involve different teams

Comment 3

[Edgar Chen [:edgar]]

Attachment: Bug 1694513 - Reject pointer lock request if we already know the focus has moved away;

Comment 4

[Phabricator Automation]

Comment on attachment 9208435 [details]
Bug 1694513 - Reject pointer lock request if we already know the focus has moved away;

Revision D107275 was moved to bug 1694698. Setting attachment 9208435 [details] to obsolete.

Comment 5

[Neha Kochar [:neha]]

Dan, do you know if bug 1366818 covers the issue #1 in comment 2?

Comment 6

[Daniel Veditz [:dveditz]]

bug 1366818 is exactly the technique (custom validity messages) abused in this specific POC. My point #1 was meant as a general design principal in case there are any other features that create similar floating panels.

Comment 7

[Andrew McCreight [:mccr8]]

Edgar, is this issue fixed? Thanks.

Comment 8

[Edgar Chen [:edgar]]

After bug 1366818, the form validity popup won't be able to show on top of the permission dialog. But the point #2 in comment #2 is still exist, page should not be able to keep the browser in pointerlock.

Comment 9

[Daniel Veditz [:dveditz]]

Linking to the eviltraps meta bug -- this technique can be used by malvertizers to add to the scariness of their dialogs about their computer being infected and that the users need to call their helpful "Microsoft" tech support number.

It's not a permanent DOS -- users can try to close the page (if they know the shortcut) or Alt-Tab to go to another app to get out, but many won't think of that.

Comment 10

[Edgar Chen [:edgar]]

(In reply to Edgar Chen [:edgar] from comment #8)

After bug 1366818, the form validity popup won't be able to show on top of the permission dialog. But the point #2 in comment #2 is still exist, page should not be able to keep the browser in pointerlock.

We move the escape key handling for pointer lock to parent process in bug 1743329 which should also fix this, so close this as RESOLVED FIXED.

Comment 11

[Simon Friedberger (:simonf)]

Attachment: advisory.txt

Comment 12

[Simon Friedberger (:simonf)]

Attachment: advisory.txt

Comment 13

[Simon Friedberger (:simonf)]

Attachment: advisory.txt