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 without the Chrome Security team. Please see https://chromium.googlesource.com/chromium/src/+/main/docs/security/ai-generated-security-bugs-faq.md for more information.

Overview: A logic flaw in Chrome’s macOS password manager potentially allows local malware to bypass the system password prompt. By pre-creating a custom authorization right with a permissive policy, an attacker can cause Chrome’s authentication checks to succeed silently. This could enable programmatic extraction of saved credentials without user interaction.

Affected files:

• chrome/browser/password_manager/password_manager_util_mac.mm

Estimated timestamp from git blame: Unknown (Google3 checkout)

Summary

The function password_manager_util_mac::EnsureAuthorizationRightExists() in chrome/browser/password_manager/password_manager_util_mac.mm contains a logic flaw that checks for the existence of an authorization right without verifying its security policy. This allows local, unprivileged malware to pre-create the right with a permissive rule (e.g., allow), causing subsequent authentication prompts to be silently bypassed by macOS.

Technical Details

Chrome uses macOS Authorization Services to protect sensitive actions like viewing or exporting saved passwords. It defines a custom right (e.g., com.google.Chrome.access-passwords) that requires the user to authenticate as the session owner.

In EnsureAuthorizationRightExists(), Chrome checks if this right exists:

bool EnsureAuthorizationRightExists() {
  NSString* rightName = UserAuthenticationRightName();
  // If the authorization right already exists there is nothing to do.
  if (AuthorizationRightGet(rightName.UTF8String, nullptr) ==
      errAuthorizationSuccess) {
    return true;
  }
  // ... code to create the right with kAuthorizationRuleAuthenticateAsSessionUser ...
}

The flaw lies in passing nullptr as the second argument to AuthorizationRightGet. This argument is meant to retrieve the right’s definition dictionary. Because Chrome passes nullptr, it only verifies that the right exists, but completely fails to verify that the right enforces the secure kAuthorizationRuleAuthenticateAsSessionUser policy.

According to macOS Authorization Services, any unprivileged application in the user session can create a new authorization right if it does not already exist. An attacker can create this exact right but assign it the rule kAuthorizationRuleAllow.

Potential Exploitation Steps

Note: These are potential steps based on static analysis. Our tooling agent does not currently have the ability to run code to verify a live Proof of Concept.

1. Precondition: The user has not yet viewed or exported passwords in Chrome on this machine, meaning the system authorization right (e.g., com.google.Chrome.access-passwords) has not yet been initialized in the macOS authorization database.
2. Right Poisoning: Local malware executes under the user’s unprivileged account and calls AuthorizationRightSet, targeting Chrome’s specific right name. The malware specifies the rule kAuthorizationRuleAllow.
3. Automating Chrome: The malware copies the user’s Chrome profile and launches a headless instance of Chrome using --remote-debugging-port to programmatically extract passwords.
4. Bypassing Biometrics: The malware ensures Chrome is launched in an environment where biometrics fail (e.g., a detached session or background daemon where [LAContext canEvaluatePolicy:] returns false), forcing Chrome to fall back to the system password prompt (AuthenticateUserWithNonBiometrics).
5. Triggering the Bypass: Chrome attempts to authorize the password export. EnsureAuthorizationRightExists() returns true immediately because the right exists (ignoring the poisoned rule).
6. Silent Extraction: Chrome calls AuthorizationCopyRights. macOS evaluates the right, sees the attacker’s allow rule, and immediately grants authorization without showing a UI prompt. Chrome decrypts and exports the passwords silently.

Suggested Fix

Instead of blindly trusting the right if it exists, Chrome should verify the rule dictionary to ensure it matches expectations.

bool EnsureAuthorizationRightExists() {
  NSString* rightName = UserAuthenticationRightName();
  CFDictionaryRef rightDefinition = nullptr;
  
  if (AuthorizationRightGet(rightName.UTF8String, &rightDefinition) == errAuthorizationSuccess) {
    // Verify the dictionary contains the correct rule (kAuthorizationRuleAuthenticateAsSessionUser)
    // If it does, return true. If not, proceed to recreate/overwrite the right.
  }
  // ...
}

Alternatively, Chrome could attempt to blindly overwrite the right with the correct secure rule on startup, or at minimum enforce the rule verification whenever AuthorizationRightGet succeeds.

Evaluated with Chrome root at commit: cc901875d53bf4e4fe0e01f02843871da4106e70

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.