Project Fortify, an experimental security project, has identified the following potential security issue.

Overview: A compromised renderer can bypass Incognito and enterprise policy restrictions to save passwords for its own origin into the main profile. This occurs because PasswordManager::OnPresaveGeneratedPassword relies on a DCHECK rather than a runtime check to verify if password saving is enabled. In release builds, this check is compiled out, allowing the browser to persistently write the credentials to disk.

Affected files:

• components/password_manager/core/browser/password_manager.cc
• chrome/browser/password_manager/chrome_password_manager_client.cc
• components/password_manager/core/browser/password_form_manager.cc
• components/password_manager/core/browser/password_save_manager_impl.cc
• components/password_manager/core/browser/form_saver_impl.cc

Estimated timestamp from git blame: 2024-05-27

Description

There is a potential logic flaw in the password manager that allows a compromised renderer process to bypass Incognito mode guarantees and enterprise policies (such as PasswordManagerEnabled = false) to persistently save credentials into the user’s main profile.

In components/password_manager/core/browser/password_manager.cc, the method OnPresaveGeneratedPassword relies on a DCHECK to ensure password saving is permitted:

void PasswordManager::OnPresaveGeneratedPassword(..., const FormData& form_data, ...) {
  DCHECK(client_->IsSavingAndFillingEnabled(form_data.url()));
  // ... proceeds to save the password
}

Because DCHECK macros evaluate to a no-op in official Release builds, this critical policy check is bypassed in production.

When this IPC is triggered in an Incognito session, the browser attempts to save the generated password. Because ChromePasswordManagerClient::GetProfilePasswordStore() requests the store using ServiceAccessType::EXPLICIT_ACCESS, the ProfilePasswordStoreFactory redirects the request and returns the PasswordStore of the original, non-Incognito profile. The underlying PasswordStore does not independently check if the active profile is Off-The-Record, resulting in the attacker-supplied credentials being persistently written to the main profile’s on-disk LoginDatabase.

The impact is constrained to the compromised renderer’s actual origin, as the browser securely sanitizes the incoming FormData using GetFormWithFrameAndFormMetaData(rfh) before passing it to the core PasswordManager.

Potential Steps to Reproduce

Note: These are suggested steps based on static analysis. Our tooling agent does not currently have the ability to run code to produce a working proof-of-concept.

1. Launch Chrome with a clean profile and open an Incognito window.
2. Navigate to an attacker-controlled site (e.g., https://attacker.com).
3. Assume the attacker gains Remote Code Execution (RCE) within the renderer process for their site.
4. The compromised renderer constructs a synthetic autofill::FormData representing a login form and sends the autofill::mojom::PasswordManagerDriver::PasswordFormsParsed IPC to the browser process.
5. The browser sanitizes the form to match the attacker.com origin and caches it in a PasswordFormManager.
6. The compromised renderer then requests the autofill::mojom::PasswordGenerationDriver Mojo interface and sends the PresaveGeneratedPassword IPC with the same form data and an attacker-controlled password string.
7. The browser process receives the IPC, bypasses the compiled-out DCHECK(client_->IsSavingAndFillingEnabled(...)), and proceeds to save the credential.
8. Close the Incognito window.
9. Open chrome://password-manager in the regular profile. The injected credential for https://attacker.com will be persistently saved there.

Suggested Fix

Replace the DCHECK in PasswordManager::OnPresaveGeneratedPassword with a proper runtime check that safely drops the IPC if saving is disabled:

void PasswordManager::OnPresaveGeneratedPassword(
    PasswordManagerDriver* driver,
    const FormData& form_data,
    const std::u16string& generated_password) {
  if (!client_->IsSavingAndFillingEnabled(form_data.url())) {
    return;
  }
  // ...
}

Evaluated with Chrome root at commit: ff3d2b74fa39431785bd60e51463b08fcc71ee33

Results from 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.