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: In Chrome for iOS, the widgets avatar folder is created and written to within the shared App Group container without backup exclusion attributes. As a result, the stable, unhashed Google Gaia IDs and avatar image files of all signed-in Google accounts are included in iCloud and unencrypted local backups. Anyone who obtains access to these backups can deanonymize the device owner and other linked accounts.

Affected files:

• ios/chrome/common/app_group/app_group_helper.mm
• ios/chrome/browser/signin/model/system_account_updater.mm

Estimated timestamp from git blame: 2025-02-10

Description

On iOS, files written to the shared App Group container are included in iCloud and iTunes/Finder backups by default unless they are explicitly marked with the backup exclusion attribute (NSURLIsExcludedFromBackupKey) or placed in specific non-backed-up directories (like Library/Caches or tmp).

Chrome for iOS creates a folder at {AppGroup}/Chrome/AvatarData/ to cache 32x32 PNG avatar images of signed-in accounts for widgets. However, during the creation of this folder and the subsequent file writes, the backup exclusion attribute is never set.

Furthermore, the avatar files are named using the user’s unhashed, cleartext Google Gaia ID (e.g., {GaiaID}.png), and contain their profile picture. This allows any adversary with access to device backups to deanonymize the user and identify any work, personal, or secondary Google accounts signed into the browser.

Code Analysis

1. Folder Creation without Exclusion

In ios/chrome/common/app_group/app_group_helper.mm:54-74, the directory is created but is not excluded from backups:

+ (NSURL*)widgetsAvatarFolder {
  NSString* applicationGroup = [AppGroupHelper applicationGroup];
  if (!applicationGroup) { return nil; }
  NSURL* groupURL = [[NSFileManager defaultManager]
      containerURLForSecurityApplicationGroupIdentifier:applicationGroup];
  NSURL* chromeURL = [groupURL URLByAppendingPathComponent:@"Chrome" isDirectory:YES];
  NSURL* pictureDataURL = [chromeURL URLByAppendingPathComponent:@"AvatarData"
                                                     isDirectory:YES];
  if (![[NSFileManager defaultManager] createDirectoryAtPath:pictureDataURL.path
                                 withIntermediateDirectories:YES
                                                  attributes:nil error:nil]) {
    return nil;
  }
  return pictureDataURL; // <-- Missing base::apple::SetBackupExclusion()
}

2. Filename is the Cleartext Gaia ID

In ios/chrome/browser/signin/model/system_account_updater.mm:91-95, the filename is constructed directly using the cleartext Gaia ID:

NSURL* avatar_path(NSURL* directory) const {
  return [directory URLByAppendingPathComponent:
              [gaia_id_.ToNSString() stringByAppendingPathExtension:@"png"]];
}

3. Writing Files without Exclusion

In ios/chrome/browser/signin/model/system_account_updater.mm:147-177, the avatar image data is written atomically to disk without applying the backup exclusion key to individual files:

for (const SystemIdentityInfoData& info : list) {
  NSData* data = info.avatar_data();
  if (data) {
    NSURL* path = info.avatar_path(avatar_folder);
    if ([data writeToURL:path atomically:YES]) {
      [avatars addObject:path];
    }
  }
}

Potential Trigger Path (Suggested Steps)

Note: The following steps are potential and suggested; our tooling does not currently have the capability to execute live code to verify this Proof of Concept.

1. A user launches Chrome on iOS and signs into one or more Google accounts.
2. Upon startup or identity change, SystemAccountUpdater is initialized unconditionally, registering as an observer of SystemIdentityManager.
3. SystemAccountUpdater::UpdateLoadedAccounts() retrieves the active identities and schedules a background task running WriteAvatars.
4. WriteAvatars creates {AppGroup}/Chrome/AvatarData/ and writes {GaiaID}.png files into it.
5. The user backs up the device via iCloud or performs an unencrypted backup via iTunes/Finder on a computer.
6. An attacker gains access to the backup, extracts the App Group container contents, and locates the folder Chrome/AvatarData/ to recover the unhashed Gaia IDs and profile photos of the signed-in accounts.

Suggested Fix

Exclude the AvatarData directory from backups once it is created in +[AppGroupHelper widgetsAvatarFolder]. Import base/apple/backup_util.h and call base::apple::SetBackupExclusion on the folder URL:

#import "base/apple/backup_util.h"
#import "base/apple/foundation_util.h"

// ... inside +[AppGroupHelper widgetsAvatarFolder] ...
  if (![[NSFileManager defaultManager] createDirectoryAtPath:pictureDataURL.path
                                 withIntermediateDirectories:YES
                                                  attributes:nil error:nil]) {
    return nil;
  }
  base::apple::SetBackupExclusion(base::apple::NSURLToFilePath(pictureDataURL));
  return pictureDataURL;

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.