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: A logic flaw in the Extensions API incorrectly classifies Document Picture-in-Picture windows as normal windows. This allows extensions to bypass explicit security constraints intended to prevent these always-on-top windows from entering fullscreen or maximized states.

Affected files:

• chrome/browser/extensions/browser_extension_window_controller.cc
• chrome/browser/ui/browser_window/internal/browser_window_features.cc
• chrome/browser/ui/views/frame/browser_view.cc
• chrome/browser/ui/exclusive_access/fullscreen_controller.cc
• ui/views/widget/widget.cc
• chrome/browser/ui/views/frame/picture_in_picture_browser_frame_view.cc
• chrome/browser/ui/views/frame/browser_widget.cc
• chrome/browser/extensions/api/tabs/tabs_api.cc

Estimated timestamp from git blame: 2024-11-15

Summary

Potential logic errors in the Chrome Extensions API and FullscreenController may allow a malicious extension to bypass security constraints on Document Picture-in-Picture (PiP) windows. By targeting these windows with chrome.windows.update, an extension can potentially force them into fullscreen or maximized states despite explicit internal policies prohibiting this. Since Document-PiP windows have the kFloatingWindow z-order (always-on-top), this behavior could be leveraged to create a persistent, frameless spoofing surface covering critical browser UI elements like the Omnibox.

Potential Root Causes

Our analysis of the codebase suggests the following contributing factors:

1. Incorrect Window Classification: In chrome/browser/extensions/browser_extension_window_controller.cc, GetTabsWindowType() classifies TYPE_PICTURE_IN_PICTURE windows as api::tabs::WindowType::kNormal. This makes them eligible targets for chrome.windows API calls.

2. Constraint Bypass in FullscreenController: Document-PiP windows call SetCanFullscreen(false) and SetCanMaximize(false) in BrowserView. However, FullscreenController::ToggleFullscreenModeInternal (in chrome/browser/ui/exclusive_access/fullscreen_controller.cc) appears to bypass the CanUserEnterFullscreen() check for requests where user_initiated is false, which includes all programmatic requests from extensions.

3. Direct State Manipulation: Programmatic calls to Widget::Maximize() do not appear to consult the CanMaximize() flag of the WidgetDelegate before applying the state transition to the native widget.

Potential Impact

Document-PiP windows are designed with strict state constraints to prevent them from being used for UI spoofing. The ability to force these always-on-top windows into a fullscreen or maximized state allows a malicious origin to potentially:

• Obscure the browser’s security UI (Omnibox) with content controlled by a web page.
• Create an always-on-top, frameless overlay that covers the entire screen or specific UI components to facilitate credential theft or phishing.

Suggested Reproduction Steps (Potential)

Note: These steps are based on code analysis and have not been validated with a running proof-of-concept.

1. A user visits a website that opens a Document Picture-in-Picture window.
2. An installed extension identifies this window by calling chrome.windows.getAll(). Due to the classification error, the PiP window appears with a type of ’normal'.
3. The extension calls chrome.windows.update(windowId, {state: 'fullscreen'}) or state: 'maximized' targeting the PiP window.
4. Observe if the window transitions to the requested state, sitting above other windows due to its floating z-order.

Suggested Fix

• Update chrome/browser/extensions/browser_extension_window_controller.cc to correctly classify TYPE_PICTURE_IN_PICTURE windows, or ensure they are excluded from state-changing API calls unless explicitly intended.
• Modify FullscreenController::ToggleFullscreenModeInternal to enforce CanUserEnterFullscreen() checks even for non-user-initiated requests if the target window is a Picture-in-Picture window.
• Consider adding guards in views::Widget::Maximize() and views::Widget::SetFullscreen() to consult the WidgetDelegate before proceeding with state changes.

Evaluated with Chrome root at commit: 1a8d40fc44df2088d5945c0bf53584038aa1614a

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.