PatchGap
WebKit · WebKit NetworkProcess

CVE-2024-44309

Cross Origin in WebKit NetworkProcess
Medium CVSS 6.3 webkit Cross Origin CISA KEV 🔧 Commit mapped

Overview

Medium
Severity
6.3
CVSS
No
Exploited ITW
Fixed
Fix Status
DescriptionProcessing maliciously crafted web content may lead to a cross site scripting attack. Apple is aware of a report that this issue may have been actively exploited on Intel-based Mac systems.
ComponentWebKit NetworkProcess
Bug ClassCross Origin
Tracker283095
Fix commit2815b4e29829 (WebKit/WebKit)
CWECWE-79 (Cross-site scripting)
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L
CISA KEVListed
CreditedClément Lecigne and Benoît Sevens of Google's Threat Analysis Group
Disclosed2024-11-19

Background

First-party-for-cookies check
NetworkProcess-side authorization deciding whether a given web process may access cookies for a first-party URL.
MESSAGE_CHECK
An IPC guard that terminates the connection when its condition fails.
AllowCookieAccess (tri-state)
New enum {Allow, Disallow, Terminate} separating a legitimate denial from a protocol violation.
In-the-wild / KEV
Apple reported active exploitation on Intel Macs; the CVE is on the CISA Known Exploited Vulnerabilities catalog.

Root Cause Analysis

NetworkConnectionToWebProcess gates a web process’s cookie operations (cookiesForDOM, cookiesEnabled(Sync), createFetchTask, registerURLSchemesAsCORSEnabled, invalid-message handling) on m_networkProcess->allowsFirstPartyForCookies(webProcessIdentifier, firstParty). Pre-patch that returned a plain bool and every call site did MESSAGE_CHECK(hasCookieAccess): a false result was treated as a protocol violation that TERMINATES the web process connection. That conflated two distinct situations – ’this process legitimately may not access cookies for this first party’ (should be denied quietly, returning empty) versus ’this message is malformed/malicious’ (should terminate). Because the only outcomes were allow or terminate, the first-party-for-cookies enforcement could not simply deny a cross-site cookie request; combined with how the result was consumed this left a cookie-management flaw that, per Apple, was exploited in the wild for cross-site scripting on Intel Macs (the precise XSS chain – cross-site cookie read/injection feeding script execution – is not shown by the diff and is inference).

The fix replaces the bool with a tri-state NetworkProcess::AllowCookieAccess { Allow, Disallow, Terminate }: MESSAGE_CHECK now only fires (terminating) on the Terminate result, and each cookie path additionally returns early/empty when the result is not Allow (if (allowCookieAccess != Allow) return ...).

The restored invariant is that a disallowed first-party cookie request is denied (no data, no cross-site access) without either leaking cookies or crashing, and only genuinely invalid requests terminate the connection.

Key insight
Cookie first-party access was a binary allow-or-terminate decision that could not cleanly deny a cross-site cookie request; a tri-state Allow/Disallow/Terminate lets the NetworkProcess refuse disallowed cookie access without leaking it or crashing – closing an in-the-wild XSS vector.

Attack Path

  1. Drive cookie requests from a web process Issue cookie operations (cookiesForDOM/cookiesEnabled/fetch) for a first-party URL the process should not have cookie access to.
  2. Exploit the binary check Pre-patch the allow/terminate-only decision mishandles the ‘disallowed’ case, failing to cleanly deny the cross-site cookie request.
  3. Obtain cross-site cookie access [inference] The mishandling lets the process read/influence cookies for another site’s first party.
  4. Escalate to XSS [inference] The cross-site cookie manipulation is leveraged into script execution in another origin – the in-the-wild XSS Apple reported on Intel Macs.

Impact Assessment

An exploited-in-the-wild cookie-management/access-control flaw in the NetworkProcess first-party-for-cookies enforcement, described by Apple as leading to cross-site scripting. It is an isolation/authorization bug (not memory corruption); the diff shows the binary allow/terminate decision replaced by a tri-state that can properly deny cross-site cookie access, while the exact XSS chain is inferred. Given active exploitation it is high-impact despite the medium engine rating; enforcement runs in the NetworkProcess.

Changed Functions

FunctionChangeNotes
NetworkConnectionToWebProcess::cookiesForDOM / cookiesEnabled / cookiesEnabledSync / createFetchTask / registerURLSchemesAsCORSEnabled / didReceiveInvalidMessage
Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp
 modified Consume allowsFirstPartyForCookies as the tri-state AllowCookieAccess: MESSAGE_CHECK only on Terminate, and deny (return empty/early) when the result is not Allow, so a disallowed first party is refused without leaking cookies or crashing.
NetworkProcess::allowsFirstPartyForCookies (AllowCookieAccess)
Source/WebKit/NetworkProcess/NetworkProcess.cpp
 modified Returns Allow/Disallow/Terminate instead of a bool so callers can distinguish 'deny' from 'terminate'.

Audit Directions

  • Other bool authorization checks
    grep NetworkProcess for allow*/canAccess* predicates returning bool consumed only via MESSAGE_CHECK, where ‘deny’ and ’terminate’ are conflated.
  • Cookie access paths
    Audit every cookiesForDOM/cookiesEnabled/setCookie/fetch path to confirm a non-Allow result denies without exposing cookies.
  • First-party derivation
    Review how firstPartyForCookies is derived and validated per web process under site isolation to prevent cross-site requests.

Original Bug Report

The reporter's bug is still restricted on the tracker.
On This Page