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 Chrome Credential Provider Extension (CPE) on iOS writes cached site favicon attributes to a shared App-Group directory that is not excluded from backups. Since filenames are computed as unsalted SHA-256 hashes of login URLs and files contain raw favicon PNGs, an attacker with access to device backups can determine which websites the user has saved credentials/passkeys for. This represents a potential privacy leak of sensitive account metadata.

Affected files:

• ios/chrome/browser/credential_provider/model/credential_provider_util.mm
• ios/chrome/browser/credential_provider/model/credential_provider_service.mm
• ios/chrome/common/app_group/app_group_constants.mm

Estimated timestamp from git blame: 2022-03-31

Root Cause

In Chrome iOS, the Credential Provider Extension (CPE) shares favicon assets with the system’s AutoFill extension via the App Group container.

The directory for these favicons is created in SaveFaviconToSharedAppContainer():

// ios/chrome/browser/credential_provider/model/credential_provider_util.mm:149-154
if (![file_manager fileExistsAtPath:path]) {
  [file_manager createDirectoryAtPath:path
          withIntermediateDirectories:YES
                           attributes:nil
                                error:nil];
}

And the folder path is resolved to {AppGroup}/Chrome/SharedFaviconAttributes/ inside app_group::SharedFaviconAttributesFolder() defined in ios/chrome/common/app_group/app_group_constants.mm.

However, unlike the main credential store directory ({AppGroup}/credential_provider/) which is explicitly excluded from backups using base::apple::SetBackupExclusion (see archivable_credential_store.mm), the SharedFaviconAttributes directory and the individual files written into it are never marked with the backup exclusion attribute. As a result, iOS includes this directory in device backups by default.

Data Flow & Leak Mechanism

For saved credentials and passkeys, Chrome computes a unique filename and writes a favicon cache file:

1. Filename Generation: Chrome hashes the full credential login URL (url.spec()) using unsalted SHA-256:

   // ios/chrome/browser/credential_provider/model/credential_provider_util.mm:115-122
   NSString* GetFaviconFileKey(const GURL& url) {
     unsigned char result[CC_SHA256_DIGEST_LENGTH];
     CC_SHA256(url.spec().data(), url.spec().length(), result);
     return base::SysUTF8ToNSString(base::HexEncode(result));
   }
   

2. File Content: The saved file is a serialized FaviconAttributes archive containing either the site’s high-resolution favicon PNG (UIImagePNGRepresentation) or a fallback monogram representing the domain’s first letter.

An attacker gaining access to device backups can locate the SharedFaviconAttributes folder, extract the files, and:

• Run an offline dictionary look-up matching common login URLs against the unsalted SHA-256 filenames to instantly find saved sites.
• Deserialize the files to directly extract and view the PNG favicon images, visually identifying the websites the user has credentials/passkeys for.

Potential Steps to Reproduce

Note: These are potential steps as our analysis is static/conceptual; we do not currently execute active proof-of-concept code on live devices.

1. Save passwords/passkeys for several distinct websites in Chrome for iOS.
2. Ensure the Credential Provider Service runs (triggered on credential modification or via the weekly resync).
3. Back up the iOS device to a computer via iTunes/Finder (with encryption disabled) or sync to an iCloud backup.
4. Extract the backup and locate the directory: group.<bundle>.chrome/Chrome/SharedFaviconAttributes/
5. Inspect the filenames (which are SHA-256 digests of the login URLs) and decode the file contents using an NSKeyedUnarchiver to read the PNG favicons, visually exposing the user’s saved account domains.

Suggested Fix

Exclude the SharedFaviconAttributes directory from backups. This can be done by calling base::apple::SetBackupExclusion on the folder path inside SaveFaviconToSharedAppContainer:

// ios/chrome/browser/credential_provider/model/credential_provider_util.mm
if (![file_manager fileExistsAtPath:path]) {
  [file_manager createDirectoryAtPath:path
          withIntermediateDirectories:YES
                           attributes:nil
                                error:nil];
  base::apple::SetBackupExclusion(base::apple::NSStringToFilePath(path));
}

This mirrors the backup exclusion implementation applied to the primary credential store in archivable_credential_store.mm:213.

Evaluated with Chrome root at commit: 84065d9121f6e48f67755f0ae963cc09617e5c85

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.