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: FileSystemAccessPermissionDialog and FolderUploadConfirmation dialogs are potentially vulnerable to Enter-keyjacking on macOS. Because these dialogs focus the Cancel button but do not override the default button or enable input event activation protection, a Return/Enter keypress triggers the default OK button. On macOS, this keypress bypasses the minimum-show-time gate, potentially allowing a malicious site to instantly obtain sensitive permissions via a single primed keypress.

Affected files:

• chrome/browser/ui/file_system_access/file_system_access_permission_dialog.cc
• chrome/browser/file_select_helper.cc

Estimated timestamp from git blame: 2022-10-21

Summary

We have identified a potential security UI bypass vulnerability (Enter-keyjacking) affecting the File System Access permission dialog (FileSystemAccessPermissionDialog) and the Folder Upload Confirmation dialog (FolderUploadConfirmation) on macOS.

Due to a platform-specific keyboard event routing behavior on macOS, a user’s Return/Enter keypress can trigger the default “OK” button even when the “Cancel” button has active keyboard focus. Because these dialogs lack default button overrides and input activation protection, the triggered Return key event bypasses the standard minimum-show-time safety gate, potentially allowing an attacker to silently and instantly acquire persistent read/write file system access or confirm directory uploads.

Note: Since our testing tools do not currently support running interactive code or UI automation on macOS, these findings represent a static analysis of potential vulnerabilities in the current codebase.

Affected Components and Code Locations

1. File System Access Permission Dialog: chrome/browser/ui/file_system_access/file_system_access_permission_dialog.cc:151-170
2. Folder Upload Confirmation Dialog: chrome/browser/file_select_helper.cc:218-235

Technical Analysis and Root Cause

When these dialogs are built, they set the Cancel button as the initially focused control via .SetInitiallyFocusedField(kCancelButtonId). However, they omit both .OverrideDefaultButton(...) and .SetEnableInputProtection(true).

1. Mac-Specific Key Routing: On macOS, PlatformStyle::kReturnClicksFocusedControl is defined as false (ui/views/style/platform_style.h:56), meaning a Return keypress does not activate a focused non-default button (like the focused “Cancel” button).
2. Fallback to Default OK Button: Because the focused Cancel button refuses to consume the Return key, the event falls through to the window’s FocusManager. Since the dialog does not override the default button, the OK button remains the default, registering a VKEY_RETURN accelerator in LabelButton::SetIsDefault(true) (ui/views/controls/button/label_button.cc:307). The FocusManager therefore routes the Return key to the OK button.
3. Input Protection Gate Bypass: When the programmatically triggered click is evaluated in DialogClientView::ButtonPressed, it queries IsPossiblyUnintendedInteraction in InputEventActivationProtector (ui/views/input_event_activation_protector.cc:38). Because the dialog model did not call SetEnableInputProtection(true), allow_key_events evaluates to true. Under this condition, the protector immediately returns false on any key event without verifying if the minimum-show-time (the protection duration) has elapsed.

As a result, a fresh Return keypress instantly confirms the dialog regardless of how long the dialog has been visible.

Suggested Exploitation Steps

A potential attack scenario would proceed as follows:

1. The attacker’s page previously retrieved a FileSystemFileHandle or FileSystemDirectoryHandle (e.g. from a prior file picker session) and saved it in IndexedDB.
2. The user visits the page on macOS, and the page displays a social-engineering prompt (e.g., “Click to start, then immediately press Enter to play”).
3. The user’s mouse click satisfies the transient activation requirement, and the page immediately calls handle.requestPermission({mode: 'readwrite'}) or initiates a folder upload.
4. The tab-modal dialog is instantly shown with the “Cancel” button focused but the “OK” button set as default.
5. The user’s primed Return keypress bypasses the safety gate and immediately runs the acceptance callback, granting persistent read/write permissions to the attacker.

Suggested Fix

To mitigate this issue, both affected dialog builders should be updated to ensure that keyboard shortcuts cannot accidentally confirm the dialog immediately upon display.

1. Override Default Button: Configure the dialog builder to set the Cancel button as the default dialog button, similar to how it is handled in FileSystemAccessDangerousFileDialog:

   dialog_builder.OverrideDefaultButton(ui::mojom::DialogButton::kCancel);
   

2. Enable Input Protection: Explicitly enable input protection to enforce the minimum show-time gate for all inputs, including keyboard shortcuts:

   dialog_builder.SetEnableInputProtection(true);
   

Evaluated with Chrome root at commit: 3947e01999a53d4e2382e39736cb79d79c7dffcf

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.