diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 91c0f338a63..4de76af8d47 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -997,6 +997,7 @@ - [ios Heap Exploitation](binary-exploitation/ios-exploiting/ios-example-heap-exploit.md) - [ios Physical UAF - IOSurface](binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md) - [Webkit Dfg Store Barrier Uaf Angle Oob](binary-exploitation/ios-exploiting/webkit-dfg-store-barrier-uaf-angle-oob.md) + - [XNU vm_map COW Aliasing and Vnode TOCTOU](binary-exploitation/ios-exploiting/xnu-vm-map-cow-vnode-toctou.md) # 🤖 AI - [AI Security](AI/README.md) diff --git a/src/binary-exploitation/ios-exploiting/README.md b/src/binary-exploitation/ios-exploiting/README.md index 857297a6ef6..31060ecf117 100644 --- a/src/binary-exploitation/ios-exploiting/README.md +++ b/src/binary-exploitation/ios-exploiting/README.md @@ -1195,6 +1195,12 @@ webkit-dfg-store-barrier-uaf-angle-oob.md imessage-media-parser-zero-click-coreaudio-pac-bypass.md {{#endref}} +### XNU `vm_map` COW Aliasing and Vnode TOCTOU + +{{#ref}} +xnu-vm-map-cow-vnode-toctou.md +{{#endref}} + ## References - [1] [Examining Pointer Authentication on the iPhone XS - Project Zero](https://googleprojectzero.blogspot.com/2019/02/examining-pointer-authentication-on.html) diff --git a/src/binary-exploitation/ios-exploiting/xnu-vm-map-cow-vnode-toctou.md b/src/binary-exploitation/ios-exploiting/xnu-vm-map-cow-vnode-toctou.md new file mode 100644 index 00000000000..1196ede79b4 --- /dev/null +++ b/src/binary-exploitation/ios-exploiting/xnu-vm-map-cow-vnode-toctou.md @@ -0,0 +1,114 @@ +# XNU vm_map COW Aliasing and Vnode TOCTOU Exploitation + +{{#include ../../banners/hacktricks-training.md}} + +## Scope and confidence + +Google Threat Intelligence confirmed that DarkSword chained a `vm_map` copy-on-write bug (CVE-2025-43510) into an arbitrary-call primitive in `mediaplaybackd`, then used a VFS race (CVE-2025-43520) to obtain physical and virtual kernel read/write. Apple describes the observable impacts as unexpected cross-process shared-memory changes and kernel-memory writes. Both primary sources place the fixes in **iOS/iPadOS 18.7.2 and 26.1**.[[1]](#references)[[2]](#references) + +> [!WARNING] +> The vulnerable routines, message geometry, vnode operation and final primitive conversion have not been published. The exploitation details below are an **audit and exploit-development model**, not a reconstruction of DarkSword. The secondary analysis that proposed this model also labels it illustrative.[[10]](#references) + +## Mach OOL COW aliasing + +Mach and XPC transport large out-of-line (OOL) data as `vm_map_copy` objects. Copyout/overwrite code must keep a destination entry's address range, backing `vm_object`, object offset, current/max protections and COW state mutually consistent while maps and objects are locked and unlocked. `vm_map_copy_overwrite_nested()` is one of the paths that overlays a copy on an existing destination range.[[3]](#references) + +For a private writable destination, one of these post-conditions must hold:[[3]](#references) + +1. the destination owns a detached writable object; or +2. it still shares the source object, but its first write must fault and perform the COW split. + +A useful audit target is a path where the destination becomes writable/private while retaining the source object **and** no longer has a write-fault path. This creates a writable cross-process alias: stores in the receiving task modify pages still consumed by the sender. Review fast paths, partial-entry clipping, submaps, page-shift conversions, error unwinding and every map-lock drop/reacquisition for invariant changes.[[3]](#references)[[10]](#references) + +```c +/* Invariant-oriented pseudocode, not vulnerable XNU code. */ +overwrite(dst_map, dst_addr, copy); + +if (dst_entry->writable && dst_entry->object == src_entry->object) { + assert(dst_entry->needs_copy || object_enforces_symmetric_cow); +} +assert(dst_entry->offset + entry_size does_not_overflow); +assert(object_reference_is_held(dst_entry->object)); +``` + +### Turning an alias into a daemon pivot + +When the compromised process is sandboxed, enumerate its signed `com.apple.security.exception.mach-lookup.global-name` entitlement and prioritize reachable daemons that accept OOL objects and possess more useful Mach/IOKit entitlements. A cross-process alias can disclose the daemon's ASLR slide and modify writable control state. Reusing already signed code pointers or legitimate call sites is preferable to forging PAC values. In the confirmed DarkSword chain, the resulting call primitive was used to load a JavaScriptCore runtime into `mediaplaybackd` and run the next stage there.[[1]](#references)[[10]](#references) + +## VFS temporary-unlock races + +XNU path lookup passes reference-counted vnodes through `namei()`/`lookup()`. A vnode includes a mutex, identity/generation state and counters such as `v_kusecount`, `v_usecount` and `v_iocount`; a lock alone is not an ownership reference.[[4]](#references)[[5]](#references) + +Audit any path that performs this sequence:[[4]](#references)[[5]](#references) + +1. resolve a vnode and validate a property; +2. drop a lock for allocation, `copyin`, filesystem callout, mount traversal or re-lookup; +3. resume with a cached pointer or previously checked field; and +4. dispatch through vnode state without proving that the reference and vnode identity survived. + +The exploitable condition is not merely an unlock. A path must also lose or omit the reference that prevents recycling, or otherwise allow the checked identity to change. Correct fixes normally retain the required iocount/usecount across the window or revalidate identity and properties after reacquiring the lock.[[4]](#references)[[5]](#references)[[10]](#references) + +### Same-type replacement under `kalloc_type` + +Modern XNU segregates typed allocations and isolates pure byte buffers in `KHEAP_DATA_BUFFERS`; the latter is specifically intended for byte bags without pointers or length/offset fields. Consequently, reclaiming a freed vnode with arbitrary pipe bytes is not the expected strategy. Groom the relevant vnode allocation population, create controlled holes, then reclaim with another **vnode** produced through legitimate filesystem operations.[[6]](#references)[[7]](#references) + +A repeatable laboratory strategy is:[[10]](#references) + +- synchronize racing threads with barriers and comparable QoS so the intended syscall reaches the unlock window consistently; +- allocate many same-type objects with `open()` on disposable paths; +- release selected objects with carefully ordered close/unlink/rename operations; and +- immediately create attacker-selected replacement paths, while separately grooming data-buffer allocations needed by the later primitive. + +The replacement remains a legitimate vnode: the filesystem chooses its valid `v_op`, and `v_data`, mount, type, flags and filesystem-private state are only as controllable as normal object construction permits. Exploitation therefore requires a continuation whose stale assumptions turn those legitimate replacement fields into a useful dereference.[[5]](#references)[[10]](#references) + +### Legitimate callback as a small kernel write + +A candidate conversion is a stale continuation that reaches `VNOP_SETATTR(vp, vap, ctx)`. If the replacement vnode selects a compatible legitimate filesystem callback, an attacker-controlled `vnode_attr` supplies a value, and the callback's destination base can be influenced, an ordinary inode-field update can become a small targeted write:[[10]](#references) + +```c +/* Primitive shape only. */ +*((uint32_t *)(vp->v_data + field_offset)) = vap->va_uid; +``` + +This requires control or a reliable relationship for both the destination and the stored value; merely reclaiming the vnode does **not** provide write-what-where.[[10]](#references) + +## Primitive ladder and data-only post-exploitation + +The modeled ladder uses one small write to corrupt metadata that bounds I/O for an existing data-buffer allocation. Enlarging the recorded length can turn normal reads/writes into an out-of-bounds slab primitive without reclaiming a typed object with raw bytes. Leaks can then be searched for build-specific `proc` signatures (`p_pid`, `p_comm` and list links), followed into task/credential state, and upgraded into stable virtual kernel read/write. Google confirms that DarkSword ultimately built physical and virtual R/W, but has not published this pipe-based conversion.[[1]](#references)[[10]](#references) + +Once kernel R/W exists, modern exploitation can avoid kernel text and direct page-table edits. Build-specific targets include credential IDs, MAC/sandbox policy state, `proc` code-signing flags and task JIT policy. PPL/SPTM protects important executable mappings and page-table transitions, but changing ordinary writable policy data may cause trusted code to authorize later operations without violating those page protections. Exact fields and integrity checks must be recovered for the target build; blindly applying offsets or clearing labels is likely to panic the device.[[8]](#references)[[10]](#references) + +## Firmware triage with `ipsw` + +The [`ipsw`](https://github.com/blacktop/ipsw) workflow can locate firmware, extract only the kernelcache, compare function-start tables, query signed entitlements and recover daemon Objective-C interfaces. Use adjacent vulnerable/patched builds, then map localized binary deltas back to the matching public XNU tag; equal file sizes or unchanged kernel banners do not imply equal code.[[9]](#references)[[10]](#references) + +```bash +ipsw download appledb --os iOS --version "18.7.2" --urls +ipsw info --remote --no-color "https://.../Restore.ipsw" +ipsw extract --kernel --remote "https://.../Restore.ipsw" +ipsw kernel version ./kernelcache.release.* +ipsw macho info --fileset-entry com.apple.kernel --starts ./kernelcache.release.* +ipsw ent --sqlite ents.db --ipsw ./Restore.ipsw +ipsw ent --sqlite ents.db --file mediaplaybackd +``` + +For generic Mach-O entitlement parsing and large-scale IPSW indexing, see [Mach-O Entitlements Extraction & IPSW Indexing](../../generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/mach-o-entitlements-and-ipsw-indexing.md). + +## Detection on research devices + +Useful correlations are OOL-heavy GPU-to-media-daemon XPC traffic without playback activity; unexpected memory-entry operations by that daemon; short bursts of `open`/`unlink`/`rename` on writable temporary paths combined with pipe allocation; and credential, sandbox or code-signing-state changes without an expected process transition. EndpointSecurity can expose filesystem bursts, while XPC/kernel instrumentation is generally limited to research or otherwise instrumented devices.[[10]](#references) + +## References + +- [1] [Google Threat Intelligence - The Proliferation of DarkSword: iOS Exploit Chain Adopted by Multiple Threat Actors](https://cloud.google.com/blog/topics/threat-intelligence/darksword-ios-exploit-chain) +- [2] [Apple - About the security content of iOS 26.1 and iPadOS 26.1](https://support.apple.com/en-us/125632) +- [3] [Apple XNU source - vm_map.c (xnu-11417.140.69)](https://github.com/apple-oss-distributions/xnu/blob/xnu-11417.140.69/osfmk/vm/vm_map.c#L9522) +- [4] [Apple XNU source - vfs_lookup.c (xnu-11417.140.69)](https://github.com/apple-oss-distributions/xnu/blob/xnu-11417.140.69/bsd/vfs/vfs_lookup.c#L1233) +- [5] [Apple XNU source - vnode_internal.h (xnu-11417.140.69)](https://github.com/apple-oss-distributions/xnu/blob/xnu-11417.140.69/bsd/sys/vnode_internal.h#L159) +- [6] [Apple Security Research - Towards the next generation of XNU memory safety](https://security.apple.com/blog/towards-the-next-generation-of-xnu-memory-safety/) +- [7] [Apple XNU source - kalloc.h data-buffer and typed-allocation definitions](https://github.com/apple-oss-distributions/xnu/blob/xnu-11417.140.69/osfmk/kern/kalloc.h#L114) +- [8] [Apple Platform Security - Operating system integrity](https://support.apple.com/guide/security/operating-system-integrity-sec8b776536b/web) +- [9] [blacktop/ipsw - Apple firmware research toolkit](https://github.com/blacktop/ipsw) +- [10] [8kSec - Inside the DarkSword Kernel Escalation: From GPU Process to Kernel R/W](https://8ksec.io/darksword-kernel-escalation-cve-2025-43510-43520) + +{{#include ../../banners/hacktricks-training.md}}