Skip to content

Latest commit

 

History

History
94 lines (79 loc) · 12.8 KB

extensions_debugger_api.md

File metadata and controls

94 lines (79 loc) · 12.8 KB

Extensions Debugger API (chrome.debugger) Security Analysis

1. Component Focus

  • API: chrome.debugger (API Docs)
  • Permissions: Requires the debugger permission in the extension manifest.
  • Functionality: Allows extensions to attach to targets (tabs, workers, other extensions, browser process identified by tabId, extensionId, or targetId) and interact with them using the Chrome DevTools Protocol (CDP). This grants extensive control over the target, making robust security enforcement critical.
  • Implementation:
    • Frontend API logic: chrome/browser/extensions/api/debugger/debugger_api.cc.
    • Backend CDP Handlers: Distributed across relevant components (e.g., content/browser/devtools/protocol/page_handler.cc, network_handler.cc, etc.).

2. Potential Logic Flaws & VRP Relevance

The chrome.debugger API presents a significant attack surface due to its high privilege level. Flaws can lead to sandbox escapes, policy bypasses, cross-origin data theft, and local file access. Key areas of concern identified through code review and VRP data include:

  • Insufficient Permission/Policy Enforcement During Command Execution: The core debugger.sendCommand function (DebuggerSendCommandFunction::Run in debugger_api.cc) does not re-verify permissions based on the specific command or parameters being sent. It relies entirely on the prior attachment being valid and the backend CDP handler for the target (e.g., in the renderer process, browser process, or service worker) to enforce necessary security checks (host permissions, file access, policy blocking, specific API access rights, etc.) for the specific command being executed. Many historical vulnerabilities stemmed from backend handlers failing to perform these checks.
    • VRP Pattern (Policy Bypass - runtime_blocked_hosts): Backend handler for Network.getAllCookies didn't check runtime_blocked_hosts. (VRP: 40060283; VRP2.txt#8615, #16467, #13706 - Reading blocked host cookies). Note: Page.navigate handler also lacks explicit policy re-check.
    • VRP Pattern (File Access Bypass): Backend handlers for specific CDP methods didn't check the extension's file access permission or allowed access to sensitive schemes (file:) inappropriately.
      • Page.navigate to file: (VRP: 40060173; VRP2.txt#7661). Note: The Page.navigate handler does check may_read_local_files_, but this relies on the flag being correctly set at attachment time.
      • Page.captureSnapshot/Page.captureScreenshot reading local files (VRP2.txt#1116444, #1116445, #3520, #6009, #7621).
      • DOM.setFileInputFiles reading local files (VRP2.txt#15188).
  • Insufficient Permission/Policy Enforcement During Attachment: Initial attach checks (ExtensionMayAttachToAgentHost, ExtensionMayAttachToURL in debugger_api.cc) might be bypassed in certain scenarios (e.g., timing races during navigation, incorrect target identification, specific URL scheme handling).
    • VRP Pattern (Cross-Profile/Incognito Access): Attaching via targetId historically bypassed profile/incognito checks, allowing access to tabs the extension shouldn't control. (VRP: 40056776).
    • VRP Pattern (Navigation Timing/Race Exploits): Exploiting timing during navigation or crash recovery to attach to or inject script into privileged pages (WebUI, DevTools) before detachment logic triggers or uses stale state. (VRP: 41483638; VRP2.txt#67, #1446, #5705, #1487).
    • VRP Pattern (Interstitial Bypass): Using navigation races to bypass security interstitials like SSL warnings. (VRP2.txt#12764).
  • Sandbox Escapes via Privileged Targets/Actions: Attaching to privileged pages or using powerful CDP methods whose backend handlers lack sufficient checks, effectively granting the extension elevated privileges.
    • VRP Pattern (DevTools Pages): Various bypasses allowing script execution in devtools:// pages. (VRP2.txt#11249, #12783, #12809, #13361, #11815). See devtools.md.
    • VRP Pattern (WebUI Pages): Code injection via debugger attachment races or lifecycle events allowing interaction with sensitive WebUI pages. (VRP: 41483638; VRP2.txt#67, #1446, #5705, #509 (chrome://downloads), #647 (chrome://feedback)). See relevant component pages.
    • VRP Pattern (File Download Bypass): Page.downloadBehavior command bypassed dangerous download checks. (VRP2.txt#16391).
    • VRP Pattern (External Program Launch): Combining debugger attachment with UI interaction simulation methods to launch downloaded executables. (VRP2.txt#7982 (debugger + downloads UI), #351 (Input.dispatchKeyEvent + WebUI), #1178 (Input.synthesizeTapGesture + chrome://downloads)).
  • Command/Target Spoofing & Race Conditions: Manipulating targets or exploiting timing issues in the debugger API itself.
    • VRP Pattern (Target Attachment Bypass): Using internal CDP methods like Target.attachToTarget or Target.setAutoAttach + Target.sendMessageToTarget to attach to disallowed targets. (VRP2.txt#16364, #331).
    • VRP Pattern (Navigation Control Bypass): Page.navigate affecting wrong/unattached frames or privileged targets due to insufficient frame/target validation. (VRP2.txt#6034, #1487, #7661).
  • Insufficient Input/Parameter Validation: Backend CDP handlers not robustly validating parameters received via sendCommand (potentially leading to crashes or unexpected behavior, although less common for direct privilege escalation).

3. Further Analysis and Potential Issues

  • Permission Check Completeness (CDP Handlers): Do all relevant backend CDP handlers correctly re-check extension permissions/policies (host permissions, file access, runtime_blocked_hosts, etc.) before executing potentially sensitive actions? This remains the primary area for potential high-severity vulnerabilities. Focus on newly added CDP methods or those interacting with sensitive browser features (files, network, UI).
  • Attachment Checks (ExtensionMayAttachTo...): Audit these functions for edge cases, especially around different URL schemes (blob:, filesystem:, inner URLs), about:blank/srcdoc, incognito profiles, and navigation timing. How is IsRestrictedUrl implemented and is it sufficient for all schemes? What happens if the target is an error page (chrome-error://)? (Related to VRP2.txt#12764). Could these checks be bypassed, allowing attachment where may_read_local_files_ or is_trusted_ are incorrectly determined?
  • Target ID Security: Is attaching via targetId truly secure across profiles/incognito now? How are browser process targets handled? Are there ways to leak or guess targetIds?
  • Navigation Timing/Race Conditions: Audit attach/detach logic (RenderFrameDevToolsAgentHost::OnNavigationRequestWillBeSent) vs. navigation lifecycle events (DidCommitProvisionalLoad, etc.). Does it correctly handle redirects, crashes, reloads? Does it always use the correct URL (committed vs. pending vs. Site URL) for checks?
  • Error Page/Crash Handling: Secure state management during target errors/reloads. Can attachment persist incorrectly or allow re-attachment to a privileged context? (VRP2.txt#1446, #1487).
  • Protocol Method Interactions: Can sequences of CDP commands bypass checks that individual commands would trigger? E.g., setting up state with one command and exploiting it with another.
  • Protocol Version Enforcement: Is v1.3 strictly enforced for sendCommand? How are newer protocol methods vetted for security implications when exposed via this API?

4. Code Analysis

  • chrome/browser/extensions/api/debugger/debugger_api.cc:
    • DebuggerFunction::InitAgentHost: Finds the DevToolsAgentHost for the target. Calls initial permission checks.
    • ExtensionMayAttachToAgentHost / ExtensionMayAttachToWebContents / ExtensionMayAttachToURL: Perform initial attach checks (profile matching, host permissions via PermissionsData::IsRestrictedUrl/IsPolicyBlockedHost, file access via util::AllowFileAccess, WebUI/interstitial/DevTools/Extension URL checks). Critically relies on potentially stale URLs during navigation. Sets flags like may_read_local_files_ and is_trusted_ for the client host based on these checks.
    • DebuggerAttachFunction: Validates permission via InitAgentHost, creates ExtensionDevToolsClientHost.
    • ExtensionDevToolsClientHost::Attach(): Attaches client to agent host.
    • DebuggerSendCommandFunction: Finds existing ExtensionDevToolsClientHost (via InitClientHost, verifying prior attachment based on extension_id and agent_host_) and calls SendMessageToBackend (line ~890). No command-specific permission checks here.
    • ExtensionDevToolsClientHost::SendMessageToBackend: Formats raw CDP command and sends via agent_host_->DispatchProtocolMessage (line ~558) without further validation or permission checks. Relies entirely on backend handler.
  • content/browser/devtools/protocol/page_handler.cc:
    • PageHandler::Navigate (handles Page.navigate):
      • Checks if URL is valid.
      • Checks gurl.SchemeIsFile() && !may_read_local_files_ (using flag set during attachment).
      • Checks gurl.SchemeIs(kChromeUIUntrustedScheme) && !is_trusted_ (using flag set during attachment).
      • Sets initiator origin correctly for the navigation using navigation_initiator_origin_ (from extension origin).
      • Does NOT explicitly re-check for policy-blocked hosts. Relies on initial attachment check and/or NavigationThrottles.
  • RenderFrameDevToolsAgentHost::OnNavigationRequestWillBeSent (content/browser/devtools/render_frame_devtools_agent_host.cc): Detaches on navigation to disallowed URLs. Potential race conditions.

5. Areas Requiring Further Investigation

  • CDP Command Handler Audit: Systematically audit backend CDP method handlers invoked via debugger.sendCommand (e.g., for Page.captureSnapshot, Network.getAllCookies, DOM.setFileInputFiles) to ensure they correctly re-verify necessary extension permissions/policies.
  • Attachment Permission Logic (ExtensionMayAttachTo...): Deep dive into the attachment permission checks in debugger_api.cc. Can timing issues during navigation lead to incorrect assessment of the target URL/state, bypassing checks or incorrectly setting flags like may_read_local_files_?
  • Target ID Validation: Rigorous checks for targetId usage, especially cross-profile/incognito.
  • Navigation/Lifecycle Race Conditions: Detailed analysis of attach/detach logic vs. navigation/lifecycle events.
  • Error/Crash State: Secure state management upon target termination.

6. Related VRP Reports

  • VRP.txt: 40056776 (Cross-Profile/Incognito Attach), 40060173 (Page.navigate file:// bypass), 40060283 (Policy bypass getAllCookies), 41483638 (WebUI Injection via attach race)
  • VRP2.txt:
    • Targeting/Attachment: #331 (setAutoAttach+sendMessageToTarget), #16364 (attachToTarget)
    • Navigation Control: #7661 (Page.navigate file://), #1487 (Privileged nav attach bypass), #6034 (Navigate unattached frame), #12764 (Interstitial bypass via navigation race)
    • Policy Bypass: #8615, #16467 (Policy bypass getAllCookies), #13706 (Policy bypass getAllCookies)
    • File Access: #1116444, #1116445, #3520, #6009, #7621 (Page.captureSnapshot/captureScreenshot file read), #15188 (DOM.setFileInputFiles file read)
    • WebUI/Privileged Page Injection: #67 (inspectedWindow.reload race + chrome://policy), #5705 (Re-attach mid-nav to WebUI), #1446 (Re-attach after crash WebUI), #509 (chrome://downloads interaction), #647 (chrome://feedback interaction)
    • DevTools Page Interaction: #11249 (DevTools msg validation), #12783, #12809 (DevTools param sanitization), #13361 (DevTools remote script load), #11815 (DevTools IPC spoof), #15887 (DevTools CSP report leak)
    • Input Synthesis Escape: #351 (Input.dispatchKeyEvent+WebUI), #1178 (Input.synthesizeTapGesture+chrome://downloads)
    • Download Bypass: #16391 (Page.downloadBehavior bypass)
    • General Sandbox Escape: #7982 (SBX via debugger + downloads UI)

(Many VRPs involved chrome.debugger, highlighting its sensitivity. This list focuses on those revealing core API or permission logic flaws).

7. Cross-References