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: The PasswordGenerationDriver Mojo interface in ChromePasswordManagerClient does not validate that the calling renderer has the privilege to access or modify password data for the target URL. If a sandboxed iframe process is compromised, it can potentially exploit this missing validation to trigger password generation or presaving under its precursor origin, bypassing Site Isolation limits on sandboxed frames. This can be resolved by adding ChildProcessSecurityPolicy checks during message handling.

Affected files:

• chrome/browser/password_manager/chrome_password_manager_client.cc

Estimated timestamp from git blame: 2021-08-11

Root Cause Analysis

In chrome/browser/password_manager/chrome_password_manager_client.cc, the browser binds and handles the autofill::mojom::PasswordGenerationDriver interface. While binding includes a check for credentialless frames:

void ChromePasswordManagerClient::BindPasswordGenerationDriver(
    mojo::PendingAssociatedReceiver<autofill::mojom::PasswordGenerationDriver> receiver,
    content::RenderFrameHost* rfh) {
  if (rfh->IsCredentialless()) {
    return;
  }
  ...
}

there are no security checks against sandboxed processes (e.g., processes running with ProcessLock.is_sandboxed() == true under the kIsolateSandboxedIframes feature) during interface binding or message execution.

Specifically, the message handlers PresaveGeneratedPassword and PasswordNoLongerGenerated in ChromePasswordManagerClient process renderer-supplied forms without verifying process capabilities via ChildProcessSecurityPolicy (CPSP):

void ChromePasswordManagerClient::PresaveGeneratedPassword(
    const autofill::FormData& form_data,
    const std::u16string& password_value) {
  content::RenderFrameHost* rfh =
      password_generation_driver_receivers_.GetCurrentTargetFrame();
  if (!password_manager::bad_message::CheckFrameNotPrerendering(rfh)) {
    return;
  }
  ...
  password_manager_.OnPresaveGeneratedPassword(
      driver,
      password_manager::GetFormWithFrameAndFormMetaData(
          password_generation_driver_receivers_.GetCurrentTargetFrame(),
          form_data),
      password_value);
}

In contrast, the sibling ContentPasswordManagerDriver interface performs validation using HasValidURL(), which delegates to bad_message::CheckChildProcessSecurityPolicyForURL() and kills the renderer process if it lacks the capability to access data for the target origin:

bool HasValidURL(content::RenderFrameHost* render_frame_host) {
  GURL url = GetURLFromRenderFrameHost(render_frame_host);
  if (!url.is_valid())
    return false;

  return password_manager::bad_message::CheckChildProcessSecurityPolicyForURL(
      render_frame_host, url,
      password_manager::BadMessageReason::CPMD_BAD_ORIGIN_FORM_SUBMITTED);
}

For sandboxed frames, ChildProcessSecurityPolicyImpl::IsAccessAllowedForSandboxedProcess restricts data access checks under AccessType::kCanAccessDataForCommittedOrigin by returning false. However, the lack of CPSP checks in the password generation pipeline allows Mojo messages to bypass this enforcement.

Potential Attack Scenario

An attacker with control of a compromised sandboxed iframe process (where IsolateSandboxedIframes is enabled) could theoretically execute the following sequence of steps:

1. The compromised process binds to the un-gated mojom::AutofillDriver interface and sends FormsSeen containing a fake form structure.
2. The browser-side AutofillDriver processes the form, retrieves the trusted precursor URL (https://victim.com), and updates its form cache.
3. The browser triggers server predictions, resulting in a call to PasswordManager::ProcessAutofillPredictions, which creates a PasswordFormManager tracking the form for the sandboxed frame’s driver.
4. The compromised process binds to mojom::PasswordGenerationDriver and sends a PresaveGeneratedPassword message containing matching form data and an attacker-controlled password.
5. Due to the missing CPSP validation in PresaveGeneratedPassword, the browser matches the existing PasswordFormManager and proceeds to save/presave the attacker’s chosen credential in the PasswordStore under the precursor origin (https://victim.com).

Note: These are potential steps. Our security review tooling does not have the capability to run code or construct a working live exploit.

Suggested Fix

Update ChromePasswordManagerClient::PresaveGeneratedPassword and ChromePasswordManagerClient::PasswordNoLongerGenerated to validate the frame’s access capability against the target URL/origin using ChildProcessSecurityPolicy before forwarding to the password manager logic, terminating the renderer process via appropriate bad message reasons if the validation fails. For example:

GURL url = password_manager::GetURLFromRenderFrameHost(rfh);
if (!password_manager::bad_message::CheckChildProcessSecurityPolicyForURL(
        rfh, url,
        password_manager::BadMessageReason::CPMD_BAD_ORIGIN_PRESAVE_GENERATED_PASSWORD)) {
  return;
}

Evaluated with Chrome root at commit: b1520ef4a76878853a31f0943b565e42060edec8

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.