[2] Attachment-element arbitrary file read via unvalidated IPC path
An <attachment> can be backed by a file on disk — and the UIProcess never checked whether the renderer had actually been handed that path.
Rated High because the diff adds a previously-missing provenance check that let a compromised renderer name any UI-process-readable file and bind its contents to an attachment; escalation to a sandbox-filesystem-escape information leak requires only a prior renderer compromise, and the /etc/passwd regression test confirms the path was reachable.
Maintain an allowlist of file paths (m_allowedAttachmentFilePaths) in WebProcessProxy that tracks paths legitimately provided to the web process via pasteboard and drag-drop operations. Validate incoming paths in RegisterAttachmentIdentifierFromFilePath against this allowlist using MESSAGE_CHECK, terminating the web process for unauthorized paths.
Source/WebKit/UIProcess/WebPageProxy.cpp
Source/WebKit/UIProcess/WebProcessProxy.cpp
Tools/TestWebKitAPI/Tests/WebKit/WKWebView/WKAttachmentTests.mm
Patch Details
The patch adds HashSet<String> m_allowedAttachmentFilePaths to WebProcessProxy, populated at every legitimate point where the UI process hands real filesystem paths to the web process: drag-drop (performDragOperation iterates dragData.fileNames()) and pasteboard reads in WebPasteboardProxyCocoa.mm via a new addAllowedAttachmentFilePaths helper. Enforcement is a new MESSAGE_CHECK_BASE(... isAllowedAttachmentFilePath(filePath), connection) in registerAttachmentIdentifierFromFilePath, terminating the web process for paths never legitimately granted. A secondary hardening adds an isValidKey check to registerAttachmentsFromSerializedData.
Missing provenance validation on a filesystem path crossing the WebContent-to-UIProcess IPC boundary, letting a sandboxed sender name files it was never granted.
Background
A WebProcessProxy is the UI-process object representing one web content process; it runs with full user privileges outside the WebContent sandbox. An <attachment> element's backing data can be a file on disk, registered by identifier; registerAttachmentIdentifierFromFilePath is the UI-process IPC handler that creates such an attachment from a path supplied by the web process. The only legitimate way the UI process exposes real filesystem paths to a renderer is when the user drags files in or pastes file URLs, at which point the UI process resolves and shares those specific paths via sandbox extensions. MESSAGE_CHECK_BASE terminates the sending process when its assertion fails.
Analysis
This is a classic confused-deputy / missing-IPC-validation bug. Before the fix, registerAttachmentIdentifierFromFilePath accepted an arbitrary filePath string from the renderer and registered an attachment backed by that path, with no check that the UI process had ever legitimately exposed it. The missing invariant: a file path used to create an attachment must trace back to a real user-driven grant (drag-drop or pasteboard read).
The UI process runs outside the WebContent sandbox and can read any file the user can read. By sending RegisterAttachmentIdentifierFromFilePath with an attacker-chosen absolute path such as /etc/passwd, a compromised renderer induces the UI process to open that file and bind its contents to an attachment identifier; the attachment data is subsequently retrievable by web content via attachment.info.data, turning a UI-process file read into a WebContent-visible info leak. This is an arbitrary-file-read / sandbox-filesystem-escape primitive, not memory corruption, and requires a pre-existing WebContent compromise to reach the IPC handler. The diff shows only the added MESSAGE_CHECK lines, so the file-open-and-return body and the attachment.info.data retrieval path are inferred from the test rather than directly visible.
This vulnerability weakens the WebContent-to-UIProcess sandbox boundary. The security model assumes the UI process only acts on filesystem paths it actively granted to a web process through a user-mediated operation; before the fix that invariant was not enforced for attachment registration, effectively handing a compromised renderer an arbitrary file-read that escapes the renderer's filesystem isolation and would aid exfiltration of credentials or tokens.
Audit directions
- Path arguments acted on without a grant check. UI/GPU/Network-process IPC handlers that accept a filesystem path or URL from a web process and open, stat, or sandbox-extend it. Audit handlers in
Source/WebKit/UIProcesstaking aString filePath/URLargument; verify each cross-references a per-process grant set comparable tom_allowedAttachmentFilePaths. Start by grepping for path/URL parameters nearMESSAGE_CHECKand compare against theSandboxExtensiongrant flow. - Capability granted at entry, unenforced at consumption. Review the attachment subsystem end-to-end (
registerAttachmentsFromSerializedData, attachment update/serialization paths) to confirm every path that reaches file I/O passes the same allowlist gate. Note that theHashSet<String>is never pruned — a path granted once stays usable indefinitely, worth examining. - Unvalidated identifier/map keys. Verify other handlers constructing map keys from web-process-supplied identifiers call
IdentifierToAttachmentMap::isValidKey(or the analogous validator) before use, as the secondary fix shows this was applied inconsistently. Grep UIProcess handlers forWTF::move(.*identifier)patterns lacking a precedingisValidKeycheck.