[1] NetworkProcess IPC File-Read Sandbox Bypass via Unvalidated replacementPath

Severity: High | Component: WebKit Network Process | c2a306a

Rated High because the observable effect is arbitrary file read from web content via a pure logic bug in IPC validation — no memory corruption required — and the test case demonstrates a complete end-to-end exploit chain with confidence 0.95, bypassing the WebContent process sandbox's file access restrictions through the Network process.

Patch Details

The patch adds validation of the replacementPath parameter in NetworkConnectionToWebProcess::registerInternalFileBlobURL. Before the fix, only the path parameter was checked against the allowed-path list via isFilePathAllowed(). The replacementPath — used for transcoded files — passed through unchecked. The fix adds two validation paths on Cocoa platforms: if a sandbox extension is provided, it calls sandbox_check() on the remote WebProcess PID to verify actual sandbox-level file-read-data access; if no sandbox extension is provided, it falls back to the existing isFilePathAllowed() check. Non-Cocoa platforms always use the allowlist check.

  Before:                                   After:
  registerInternalFileBlobURL()             registerInternalFileBlobURL()
    └─► check path ──► check replacementPath? NO     └─► check path
          └─► register blob                            └─► check replacementPath
                                                             ├─ sandbox ext? ──► sandbox_check(PID)
                                                             └─ no ext? ──► isFilePathAllowed()
                                                                  └─► register blob

Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp

LayoutTests/http/tests/security/registerBlobURL.html

Missing IPC parameter validation on an alternate file path that bypasses the primary path's access control check.

Background

WebKit's multi-process architecture splits web content rendering (WebContent process) from network operations (Network process). The WebContent process communicates with the Network process via IPC messages, and the Network process enforces file access policy when the WebContent process registers file-backed blob URLs. The registerInternalFileBlobURL IPC message accepts both a path (the original file) and a replacementPath (used when a file has been transcoded to a different format — for instance, converting a HEIC image to JPEG for web consumption). When replacementPath is non-empty, the blob registry reads content from replacementPath instead of path. MESSAGE_CHECK is WebKit's IPC validation macro — when the check fails, the Network process terminates the offending WebContent process connection. isFilePathAllowed() validates a path against an internal allowlist of files the WebContent process is authorized to reference.

Analysis

The registerInternalFileBlobURL IPC handler validated the path parameter against an allowed-paths list but did not validate replacementPath. The replacementPath parameter exists for transcoded files — when a file is transcoded, the original path is validated but the actual file content is read from replacementPath (as strongly implied by the parameter names, the fix pattern, and the working test case). A compromised or malicious WebContent process could craft an IPC message with a legitimate path (passing the allowlist check) but set replacementPath to an arbitrary file on disk. The blob registry would then serve the contents of the attacker-chosen replacement file when the blob URL was fetched.

The test case demonstrates a complete end-to-end exploit: it obtains a valid filesystem root path via FileSystemGetDirectory/GetFile, uses it as the path parameter, sets replacementPath to /private/var/db/com.apple.networkextension.tracker-info, registers the blob chain, and reads the file via fetch(blobURL). No memory corruption is needed — this is a pure logic bug in IPC validation.

Audit directions