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 without the Chrome Security team.

Overview: A potential logic flaw in the password manager allows credentials received via Google Family sharing to be used for Credential Management API (CM API) zero-click auto-signin. The handler for incoming shared credentials fails to set the skip_zero_click flag, causing the auto-signin flow to bypass the mandatory SharedPasswordsNotificationBubble security warning. This could enable an attacker in the same Family group to silently log a victim into an attacker-controlled account (Login CSRF).

Affected files:

• components/password_manager/core/browser/sharing/password_receiver_service_impl.cc
• components/password_manager/core/browser/password_form.h
• components/password_manager/core/browser/credential_manager_pending_request_task.cc
• chrome/browser/ui/passwords/manage_passwords_ui_controller.cc
• chrome/browser/password_manager/chrome_password_manager_client.cc

Estimated timestamp from git blame: 2023-11-29

Summary

There is a potential logic flaw in the handling of shared credentials that allows the Credential Management API (CM API) to perform automatic sign-ins (zero-click) using passwords received via Google Family sharing without appropriately notifying the user. This bypasses the SharedPasswordsNotificationBubble, which is the primary security mitigation designed to inform users when a shared credential is used. This can lead to a login-CSRF vulnerability where an attacker (a family member) can silently sign a victim into an attacker-controlled account on a target site.

Root Cause Analysis

The issue originates in components/password_manager/core/browser/sharing/password_receiver_service_impl.cc within the IncomingSharingInvitationToPasswordForms function. When an incoming sharing invitation is parsed into a PasswordForm object, the code accurately sets form.type = PasswordForm::Type::kReceivedViaSharing; but fails to explicitly assign a value to form.skip_zero_click.

Because skip_zero_click is defined with a default value of false in components/password_manager/core/browser/password_form.h, credentials received via sharing are persisted in the password store with skip_zero_click = false.

Potential Attacker Steps & Execution Flow

Note: These are theoretically derived steps based on code analysis; our tooling agent does not execute live code.

1. Setup: An attacker and victim are in the same Google Family group. The victim has Chrome Sync enabled and “Auto Sign-in” active (default). The victim has no existing credentials for https://target.com.
2. Sharing: The attacker creates an account on https://target.com (which uses the CM API for auto-signin) and shares the credential with the victim via Chrome.
3. Sync & Storage: The victim’s Chrome instance processes the incoming invitation via IncomingSharingInvitationToPasswordForms. The credential is saved to the SQLite database with skip_zero_click = false.
4. Navigation: The victim navigates to https://target.com/.
5. CM API Invocation: The site calls navigator.credentials.get({password:true}).
6. Validation Bypass: In CredentialManagerPendingRequestTask::ProcessForms, IsFormValidForAutoSignIn only checks for exact origin matches, completely ignoring form->type. Because the victim has exactly one credential for the site, auto-signin is permitted.
7. Zero-Click Execution: The code evaluates if (can_use_autosignin && !results[0]->skip_zero_click). Because the credential was saved with the default false value, this check passes, and the CM API auto-signin path proceeds.
8. Notification UI Bypass: The code calls NotifyUserAutoSignin, triggering ManagePasswordsUIController::OnAutoSignin. Unlike the standard autofill path (OnPasswordAutofilled), OnAutoSignin unconditionally transitions the UI to AUTO_SIGNIN_STATE (displaying a brief toast) and does not check if form->type == kReceivedViaSharing.
9. Impact: The mandatory SharedPasswordsNotificationBubble (which identifies the sender) is never displayed. The victim is silently logged into the attacker’s account.

Suggested Fix

1. In components/password_manager/core/browser/sharing/password_receiver_service_impl.cc, within IncomingSharingInvitationToPasswordForms, explicitly disable zero-click auto-signin for shared credentials:

form.skip_zero_click = true;

2. (Optional but recommended for defense-in-depth) In CredentialManagerPendingRequestTask::ProcessForms or IsFormValidForAutoSignIn, explicitly exclude credentials where type == PasswordForm::Type::kReceivedViaSharing from being eligible for auto-signin.

Evaluated with Chrome root at commit: 096fc8fdbfacf2546485756d03f160a3d04fcc9b

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