Flapjack, 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 Use-After-Free vulnerability exists in LegacyRenderWidgetHostHWND::InitOrDeleteSelf when creating an AXSystemCaretWin object. The constructor calls ::NotifyWinEvent, which can synchronously invoke a nested message loop that processes messages leading to the destruction of the window. When the constructor returns, the freed object is accessed, potentially allowing arbitrary code execution in the browser process.

Affected files:

• content/browser/renderer_host/legacy_render_widget_host_win.cc

Estimated timestamp from git blame: 2017-12-09

Summary

A Use-After-Free (UAF) vulnerability has been identified in LegacyRenderWidgetHostHWND::InitOrDeleteSelf within the browser process. This issue occurs due to a lack of re-entrancy protection when initializing the system caret (ui::AXSystemCaretWin), allowing the potential destruction of the LegacyRenderWidgetHostHWND object while the initialization method is still active on the stack.

Technical Details

In content/browser/renderer_host/legacy_render_widget_host_win.cc, InitOrDeleteSelf is responsible for setting up the legacy render widget host window. This method uses base::WeakPtr guards to protect against re-entrancy during synchronous Windows API calls that could result in the object’s destruction. However, the initialization of ax_system_caret_ lacks this protection:

// Line 260
ax_system_caret_ = std::make_unique<ui::AXSystemCaretWin>(hwnd());

// Line 263
if (!::IsWindow(hwnd())) {
  delete this;
  return false;
}

The constructor of ui::AXSystemCaretWin (located in ui/accessibility/platform/ax_system_caret_win.cc) calls ::NotifyWinEvent synchronously:

if (event_target_) {
  NotifyWinEventAndTrace(EVENT_OBJECT_CREATE, event_target_, OBJID_CARET, -caret_->GetUniqueId());
}

The call to ::NotifyWinEvent can spin a nested message loop if system hooks or accessibility tools are present. During this loop, pending IPC messages can be processed.

Potential Exploitation Path

While our automated tooling cannot run arbitrary code to confirm exploitation, the following theoretical steps describe how an attacker compromising a renderer process might trigger this:

1. A compromised renderer process sends an IPC to the browser process to create a new window or popup.
2. The browser process creates an aura window, which invokes LegacyRenderWidgetHostHWND::Create.
3. InitOrDeleteSelf executes, creating the legacy window and reaching line 260.
4. hwnd() safely evaluates, and the AXSystemCaretWin constructor runs, invoking ::NotifyWinEvent.
5. While ::NotifyWinEvent spins a message loop, the compromised renderer immediately sends a ‘close window’ IPC.
6. The browser processes the ‘close window’ IPC, which calls RenderWidgetHostViewAura::OnWindowDestroying.
7. OnWindowDestroying executes legacy_render_widget_host_HWND_.ExtractAsDangling()->Destroy();. By using ExtractAsDangling(), the raw_ptr reference is removed without being quarantined by MiraclePtr.
8. Destroy() leads to OnNCDestroy, which executes delete this;, freeing the LegacyRenderWidgetHostHWND memory.
9. The compromised renderer sprays the browser’s heap to reclaim the freed memory with a fake object containing an attacker-controlled vtable and a fake hwnd_ set to 0.
10. The nested message loop concludes, and the constructor returns.
11. InitOrDeleteSelf resumes. It assigns the returned unique pointer to ax_system_caret_ (a Write-After-Free) and evaluates if (!::IsWindow(hwnd())) (a Read-After-Free).
12. Because hwnd() returns the attacker-controlled value 0, the branch is taken, executing delete this;.
13. delete this; triggers the virtual destructor via the attacker-controlled vtable, leading to arbitrary code execution (RCE) and a sandbox escape.

Suggested Fix

Introduce a base::WeakPtr check after the creation of the AXSystemCaretWin object to ensure this has not been deleted:

  auto system_caret = std::make_unique<ui::AXSystemCaretWin>(hwnd());
  if (!ref) {
    return false;
  }
  ax_system_caret_ = std::move(system_caret);

  // If we failed to create the child, then return false.
  if (!::IsWindow(hwnd())) {
    delete this;
    return false;
  }

Evaluated with Chrome root at commit: 2155cb00003ec35716a76ed3246eae995f87b7ff

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.