Closed Bug 1743329 (CVE-2024-6608) Opened 4 years ago Closed 1 year ago

requestPointerLock on iFrame src from different origin able to move the cursor out of viewport

Categories

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

defect

Tracking

()

RESOLVED FIXED
128 Branch
Tracking Status
firefox-esr115 --- wontfix
firefox126 --- wontfix
firefox127 --- wontfix
firefox128 --- fixed

People

(Reporter: sourc7, Assigned: edgar)

References

(Blocks 1 open bug)

Details

(Keywords: csectype-spoof, reporter-external, sec-moderate, Whiteboard: [reporter-external] [client-bounty-form] [verif?][secdom:pointerlock] [adv-main128+])

Attachments

(8 files, 2 obsolete files)

After invoke requestPointerLock on iframe src from different origin, surprisingly on Fission enabled the cursor or pointer will move outside viewport including to toolbar, permission panel, desktop, taskbar, and more.

On the attached testcase I able to move user pointer to "Allow" button on permission panel, so when user double click the box, user will unaware it also click "Allow" button to allow Geolocation permission.

Tested on:

  • Firefox Nightly 96.0a1 (2021-11-28) (64-bit) on Windows 11 (with screen resolution 1920x1080)
  • Firefox Nightly 96.0a1 (2021-11-28) (64-bit) on Arch Linux (with screen resolution 2560x1440)

Steps to reproduce:

  1. Visit attached rpl-geolocation-windows.html
  2. Click "Launch" button
  3. Double click the box
  4. Geolocation permission is now allowed
Flags: sec-bounty?

Here I demonstrate I can move the cursor to the desktop, after second click the cursor will drag (steal) the desktop file back to the pointerlock area.

If dragged file is Windows shortcut .lnk by using Link Parser software it can reveal more information such as LinkCreationDate, VolumeSerialNumber, VolumeLabel, LocalBasePath, NetBIOS (Hostname), MAC Address, and more.

Steps to reproduce:

  1. Visit attached rpl-dragdropsteal-windows.html
  2. Resize the browser window (so that the left corner desktop shortcut is visible)
  3. Click Launch
  4. Double click the box
  5. File or folder in the desktop will dragged back to iFrame pointerlock area.
Group: firefox-core-security → dom-core-security
Type: task → defect
Component: Security → DOM: Core & HTML
Product: Firefox → Core
Severity: -- → S2
Priority: -- → P3
Flags: needinfo?(echen)

We could also see this without Fission if the window is small enough, but it is much worse on Fission.

so there are two things here,

  1. In the current implementation, we will try to reset the mouse position to the center position of the requesting process (via synthesizing a native mousemove event), but somehow the center position of the OOP iframe is over the notification popup, which is super weird.
  2. Once the mouse position is outside the web content, we are unable to reset its position to "lock" mouse in a specific element.

I think we need to check 1 first, it is a Fission-specific issue.
For 2, it is a known bug, https://bugzilla.mozilla.org/show_bug.cgi?id=853160#c13 might be a proper solution.

Flags: needinfo?(echen)
Whiteboard: [reporter-external] [client-bounty-form] [verif?] → [reporter-external] [client-bounty-form] [verif?][secdom:pointerlock]
Flags: sec-bounty? → sec-bounty+

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

  1. Once the mouse position is outside the web content, we are unable to reset its position to "lock" mouse in a specific element.

As a quick alternative, we could also try to set the capture content to the XULFrame in the parent document or just always redirect the mouse event to web content when pointer lock is active.

Blocks: pointer-lock

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

Assignee: nobody → echen
Depends on: 1255338
See Also: → 1889999
See Also: 1889999

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

As a quick alternative, we could also try to set the capture content to the XULFrame in the parent document or just always redirect the mouse event to web content when pointer lock is active.

On a second thought, when the permission panel (or other popup) is opened, user might expect to be able to interact with the panel. Additionally, users don't have a way to exit pointer lock without closing the popup. So I think exiting the pointer lock automatically when popup is opened has a better UX.

Attachment #9403894 - Attachment is obsolete: true
Blocks: 1898815
Pushed by echen@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/209a41c449e1 Use nsMenuPopupFrame in GetVisiblePopups(); r=smaug https://hg.mozilla.org/integration/autoland/rev/cd96c48488eb Release pointer lock when xul popup is open; r=smaug https://hg.mozilla.org/integration/autoland/rev/0f9bffa357a5 Handle ESC key to release pointer lock in parent process; r=smaug https://hg.mozilla.org/integration/autoland/rev/6d33ea38cd14 apply code formatting via Lando
Backout by abutkovits@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/405be8bb745b Backed out 4 changesets for causing failures at browser_popupNotification_security_delay.js. CLOSED TREE

Push with failures
Failure log

[task 2024-05-29T12:09:22.700Z] 12:09:22     INFO - TEST-PASS | browser/base/content/test/popupNotifications/browser_popupNotification_security_delay.js | Notification should still be open because we clicked during the security delay. - 
[task 2024-05-29T12:09:22.700Z] 12:09:22     INFO - Wait for security delay to expire.
[task 2024-05-29T12:09:28.200Z] 12:09:28     INFO - Run test specific actions which restarts the security delay.
[task 2024-05-29T12:09:28.201Z] 12:09:28     INFO - Enter pointer lock
[task 2024-05-29T12:09:28.224Z] 12:09:28     INFO - Console message: [JavaScript Warning: "Request for pointer lock was denied because the browser failed to lock the pointer." {file: "https://example.com/" line: 0}]
[task 2024-05-29T12:09:55.318Z] 12:09:55     INFO - TEST-INFO | started process screentopng
[task 2024-05-29T12:09:55.519Z] 12:09:55     INFO - TEST-INFO | screentopng: exit 0
[task 2024-05-29T12:09:55.520Z] 12:09:55     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/popupNotifications/browser_popupNotification_security_delay.js | Test timed out - 
Flags: needinfo?(echen)
Flags: needinfo?(echen)
Pushed by echen@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/809b1444b032 Use nsMenuPopupFrame in GetVisiblePopups(); r=smaug https://hg.mozilla.org/integration/autoland/rev/42fb9a1a6ff8 Release pointer lock when xul popup is open; r=smaug,pbz https://hg.mozilla.org/integration/autoland/rev/8d5d56cea3b8 Handle ESC key to release pointer lock in parent process; r=smaug
QA Whiteboard: [post-critsmash-triage]
Flags: qe-verify+
See Also: → 1887805
Blocks: 1887805
See Also: 1887805
No longer depends on: 1255338
Whiteboard: [reporter-external] [client-bounty-form] [verif?][secdom:pointerlock] → [reporter-external] [client-bounty-form] [verif?][secdom:pointerlock] [adv-main128+]
Attached file advisory.txt (obsolete) —
Attached file advisory.txt
Attachment #9411708 - Attachment is obsolete: true
Alias: CVE-2024-6608
Group: core-security-release
See Also: → 1953076
See Also: 1953076
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: