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 (UAF) vulnerability exists in the password generation popup on Windows. Synchronous re-entrancy during accessibility event firing allows a compromised renderer to trigger the destruction of the popup’s views while they are still being accessed by the browser process. This can lead to memory corruption or arbitrary code execution in the unsandboxed browser process.

Affected files:

• chrome/browser/ui/views/passwords/password_generation_popup_view_views.cc
• chrome/browser/ui/views/autofill/popup/popup_base_view.cc

Estimated timestamp from git blame: 2024-01-19

Root Cause Analysis

A potential Use-After-Free (UAF) vulnerability has been identified in PasswordGenerationPopupViewViews::ButtonSelectionUpdated on Windows. The issue stems from caching a raw pointer to a child view across a synchronous re-entrancy point triggered by Windows UI Automation (UIA).

In chrome/browser/ui/views/passwords/password_generation_popup_view_views.cc, the function ButtonSelectionUpdated caches a local pointer to nudge_password_buttons_view_ and calls NotifyAXSelection:

void PasswordGenerationPopupViewViews::ButtonSelectionUpdated() {
  // ...
  auto* nudge_password_buttons =
      static_cast<NudgePasswordButtons*>(nudge_password_buttons_view_);
  if (controller_->accept_button_selected()) {
    NotifyAXSelection(*nudge_password_buttons->GetAcceptButton()); // Re-entrancy point
  } else if (controller_->cancel_button_selected()) {
    NotifyAXSelection(*nudge_password_buttons->GetCancelButton());
  }
  nudge_password_buttons->UpdateFocus(controller_->accept_button_selected()); // Potential UAF
}

The call to NotifyAXSelection reaches PopupBaseView::NotifyAXSelection, which fires accessibility events (such as kMenuStart or kMenuPopupStart). On Windows, these events reach ::UiaRaiseAutomationEvent synchronously. When a UIA client (such as a screen reader) is active, this Windows API call can synchronously pump the message loop (STA pump).

If a compromised renderer has queued a Mojo message that triggers a state update in the popup (e.g., PasswordGenerationDriver::ShowPasswordEditingPopup), that message can be processed during this nested message loop. This results in a call to PasswordGenerationPopupViewViews::UpdateState(), which synchronously destroys the popup’s child views:

void PasswordGenerationPopupViewViews::UpdateState() {
  password_view_ = nullptr;
  nudge_password_buttons_view_ = nullptr; // Nulling member raw_ptr
  RemoveAllChildViews();                  // Synchronously deletes child views
  CreateLayoutAndChildren();
}

When the UIA pump returns, the original ButtonSelectionUpdated execution flow continues. The local pointer nudge_password_buttons now points to freed memory, and the subsequent call to UpdateFocus results in a Use-After-Free. Additionally, PopupBaseView::NotifyAXSelection may dereference a dangling reference to the selected_view after the re-entrant call returns.

MiraclePtr / BRP Protection

MiraclePtr (BRP) does not mitigate this issue because:

1. The vulnerability involves a function-local raw pointer (nudge_password_buttons) and a reference (selected_view).
2. The raw_ptr member nudge_password_buttons_view_ is explicitly set to nullptr in UpdateState() immediately before destruction, ensuring the object is not held in the quarantine when it is deleted.

Suggested Potential Reproduction Steps

1. Ensure Windows is running with an active UIA client (e.g., Narrator).
2. From a compromised renderer, trigger the password generation popup.
3. Send a Mojo message to the browser process (e.g., ShowPasswordEditingPopup) that would trigger UpdateState().
4. Trigger navigation within the popup (e.g., via a synthetic arrow key event) to cause ButtonSelectionUpdated to be called.
5. Observe the browser process dereferencing the dangling pointer in ButtonSelectionUpdated after the synchronous accessibility event firing returns.

Fix Suggestion

Avoid using raw pointers to views across calls that can trigger synchronous re-entrancy. The ButtonSelectionUpdated function should either use base::WeakPtr to track the lifetime of the NudgePasswordButtons view or re-verify the validity of nudge_password_buttons_view_ after the call to NotifyAXSelection. More broadly, firing accessibility events on Windows should be evaluated for re-entrancy safety.

Evaluated with Chrome root at commit: b3153093eb3c78c3e88ccf562bcbc20437a04b0e

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.