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. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: A potential Use-After-Free vulnerability exists in the browser process of Aura-based platforms due to reentrant window destruction during mouse locking. Invoking SetCapture() can synchronously delete the capture window and its associated event handler during touch cancellation. This can result in a Use-After-Free when the deleted window or event handler is subsequently accessed.

Affected files:

• ui/aura/window_tree_host_platform.cc
• content/browser/renderer_host/render_widget_host_view_event_handler.cc
• ui/aura/window_tree_host.cc

Estimated timestamp from git blame: 2021-07-02

Potential Use-After-Free in WindowTreeHostPlatform::LockMouse and RenderWidgetHostViewEventHandler

Description and Root Cause

A potential Use-After-Free (UAF) vulnerability exists in the browser process of Aura-based platforms (such as Linux, ChromeOS, and Fuchsia). The issue arises due to synchronous, reentrant window and view destruction during pointer locking.

Specifically, in WindowTreeHostPlatform::LockMouse (ui/aura/window_tree_host_platform.cc:226):

void WindowTreeHostPlatform::LockMouse(Window* window) {
  window->SetCapture();
  WindowTreeHost::LockMouse(window);
}

Calling window->SetCapture() can trigger a synchronous touch-cancellation flow via the gesture recognizer (ui/events/gestures/gesture_recognizer_impl.cc), which dispatches synthetic touch-cancel events (EventType::kTouchCancelled) to other active gesture consumers.

If a touch-cancel handler on another window synchronously destroys the requesting tab’s WebContents (e.g., closing a popup/dropdown or destroying the tab’s container), the target RenderWidgetHostViewAura view and its associated RenderWidgetHostViewEventHandler will be synchronously deleted.

When control returns to WindowTreeHostPlatform::LockMouse, the stack parameter window is now a dangling pointer. Furthermore, when execution returns to RenderWidgetHostViewEventHandler::LockPointer (content/browser/renderer_host/render_widget_host_view_event_handler.cc:151), both this and window_ are dangling:

  window_->GetHost()->LockMouse(window_);

  if (ShouldMoveToCenter(unlocked_global_mouse_position_)) // UAF read on this->unlocked_global_mouse_position_
    MoveCursorToCenter(nullptr);

  delegate_->SetTooltipsEnabled(false); // UAF dereference and virtual function call on this->delegate_

The subsequent call to delegate_->SetTooltipsEnabled(false) constitutes a virtual method call on a pointer (delegate_) read from freed memory. If an attacker reclaims this heap allocation before this line, it can lead to control-flow hijack and arbitrary code execution in the context of the unsandboxed browser process.

Affected Platforms

• Linux, ChromeOS, and Fuchsia (Aura-based platforms).
• Windows is unaffected because DesktopWindowTreeHostWin::LockMouse does not call SetCapture().

Potential Trigger Steps

Because our tooling agent does not currently have the ability to run or execute code, these are potential steps to trigger the issue:

1. Setup active touch state: Arrange the browser UI state such that a gesture consumer on another window has an active touch.
2. Initiate mouse lock: From the renderer process, trigger a pointer-lock request (e.g., via element.requestPointerLock()).
3. Handle touch cancellation synchronously: When the gesture recognizer dispatches EventType::kTouchCancelled to the other consumer window during the SetCapture() call, its event handler must synchronously close or destroy the target WebContents/tab (for example, by dismissing an anchored popup bubble that owns or is bound to the target view).
4. Trigger UAF: On shipping channels <= M151 (prior to M152 where a diagnostic CHECK was introduced), the deletion of the RenderWidgetHostViewEventHandler proceeds silently, and control returns to trigger the Use-After-Free reads and the virtual call dereference.

Suggested Fix

To resolve this issue, lifetime tracking should be introduced in both WindowTreeHostPlatform::LockMouse and RenderWidgetHostViewEventHandler::LockPointer to guard against reentrant destruction.

1. In WindowTreeHostPlatform::LockMouse, track the Window lifetime using a base::WeakPtr<aura::Window> or WindowTracker:

void WindowTreeHostPlatform::LockMouse(Window* window) {
  base::WeakPtr<Window> window_weak = window->GetWeakPtrAsWindow();
  window->SetCapture();
  if (!window_weak)
    return;
  WindowTreeHost::LockMouse(window);
}

2. In RenderWidgetHostViewEventHandler::LockPointer, similarly track the lifetime of this and window_ after the reentrant call:

  base::WeakPtr<RenderWidgetHostViewEventHandler> weak_this = weak_ptr_factory_.GetWeakPtr();
  window_->GetHost()->LockMouse(window_);

  if (!weak_this)
    return blink::mojom::PointerLockResult::kUnknown; // Or appropriate error

  if (ShouldMoveToCenter(unlocked_global_mouse_position_))
    MoveCursorToCenter(nullptr);

  delegate_->SetTooltipsEnabled(false);

Evaluated with Chrome root at commit: 84065d9121f6e48f67755f0ae963cc09617e5c85

Results so far have been promising, but there can be wrong deductions. Feel free to adjust as follows:

• If you are familiar with the severity guidelines, you may adjust the severity.
• If this is a false positive, and there’s no work to be done, please close as WAI.
• If there is work to do here but not a vulnerability, please change the issue type to Task/Bug/FR.

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.