Project Fortify, an experimental security project, has identified the following potential security issue. If you’re a feature owner CC-ed on this bug, please do your best to review these reports without the Chrome Security team. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: A data race on the std::unique_ptr<MouseCursor> mouse_cursor_ member in SharedScreenCastStreamPrivate can occur between the PipeWire thread and the capture thread. This lack of synchronization allows a dangling pointer to be moved to the composer, leading to a potential Use-After-Free read (information leak) and Double-Free in the unsandboxed browser process.

Affected files:

• third_party/webrtc/modules/desktop_capture/linux/wayland/shared_screencast_stream.cc
• third_party/webrtc/modules/desktop_capture/linux/wayland/mouse_cursor_monitor_pipewire.cc
• third_party/webrtc/modules/desktop_capture/desktop_and_cursor_composer.cc

Estimated timestamp from git blame: 2024-06-27

Root Cause

A thread safety issue exists in SharedScreenCastStreamPrivate within the WebRTC desktop capture module for Linux/Wayland (third_party/webrtc/modules/desktop_capture/linux/wayland/shared_screencast_stream.cc). The member mouse_cursor_ (a std::unique_ptr<MouseCursor>) is accessed and modified without synchronization from two different threads:

1. Writer (PipeWire thread): The background pipewire-main-loop thread invokes ProcessBuffer(), which creates a new MouseCursor object and assigns it to mouse_cursor_ (line 777). This assignment is performed without holding any mutex.
2. Reader (Capture thread): The desktopCaptureThread (an unsandboxed thread in the browser process) calls CaptureCursor(), which executes return std::move(mouse_cursor_); (line 702). This is also performed without synchronization.

Vulnerability Details

Because std::unique_ptr assignment and move operations are not atomic, concurrent execution leads to a data race on the internal raw pointer.

1. The Reader thread executes std::move(mouse_cursor_) and reads the raw pointer just before the Writer thread completes its assignment of a new cursor.
2. The Writer thread completes its assignment, which triggers the deletion of the old MouseCursor object.
3. The Reader thread completes its move, successfully constructing a new unique_ptr that wraps the now-freed pointer.

This leads to two distinct impacts:

• Use-After-Free (Information Leak): The dangling pointer is passed to DesktopAndCursorComposer::OnMouseCursor(). During frame composition, DesktopFrameWithCursor calls AlphaBlend, which reads from the freed MouseCursor’s image data and copies it into the captured video frame. This blends browser-process heap memory into the video stream sent back to the web page.
• Double-Free (Potential RCE): The DesktopAndCursorComposer stores the dangling pointer in its own std::unique_ptr<MouseCursor> cursor_. When a new cursor is received, or upon destruction, cursor_.reset() is called, which attempts to delete the already-freed pointer a second time. Because MouseCursor manages a DesktopFrame with a virtual destructor, this provides a primitive for control-flow hijacking in the unsandboxed browser process.

Potential Attack Steps

(Note: These are suggested steps based on code analysis; a working PoC has not been executed.)

1. An attacker tricks a victim on Linux (Wayland/PipeWire) into visiting a malicious site.
2. The site calls navigator.mediaDevices.getDisplayMedia({ video: true }).
3. Once the user grants permission, the browser process begins capturing the screen using the vulnerable Wayland module.
4. The malicious page rapidly alters CSS cursor shapes or prompts the user to move the mouse rapidly while capturing frames at a high rate. This maximizes the execution frequency of both threads to win the race condition.

Suggested Fix

Access to mouse_cursor_ and mouse_cursor_position_ must be synchronized. Since queue_lock_ and latest_frame_lock_ already exist in SharedScreenCastStreamPrivate, one of these mutexes (or a new dedicated mutex) should be held during both the assignment in ProcessBuffer() and the read/move in CaptureCursor() and CaptureCursorPosition().

Evaluated with Chrome root at commit: 7353d249d9cacf9c7218e1d7b8a39cf39c72d646

Results so far have been promising, but there can be wrong deductions. If this proves to be a false positive, please close as WAI; data from false positives will be used to improve accuracy over time. And please feel free to reach out to me directly if you have concerns or feedback on the project.