worse_query Escape

How worse_query works (and why bad_query was patched)

Published by Taj C (forcequitOS/worse_query, 587 stars, GPL-3.0) and documented in detail by murk-sus/kamui-escape and kolbicz/WQFiles, worse_query is a container-level sandbox escape targeting Apple’s containermanagerd (MobileContainerManager / MCM).

Its predecessor, bad_query, passed relative path traversal (../../../../../../../..) inside container_query_operation_set_part_domain on MCM class 13 (`SystemGroup`). In iOS 27.2, Apple patched bad_query in two places:

1. MCMXPCMessageQuery explicitly rejects any query whose partDomain contains .. (logging Rejecting query with invalid partDomain).
2. MCMFileManager realPathForURL:ifChildOfURL: resolves symlinks and rejects targets outside the container when partDomain is non-empty.

The class-7 part-directory symlink primitive

Apple’s iOS 27.2 fix validated partDomain, but it did not validate the container’s part directory itself when partDomain is left empty:

1. Inside the app’s own container (MCM class 2), iOS 27.2 sandbox rules block rename() on Library/Caches, Library/Preferences, Documents, and tmp with EPERM (errno 1).
2. However, inside an App Group container (MCM class 7), the part directory <app group>/Library/Caches remains writable and renameable by the app.
3. worse_query backs up <app group>/Library/Caches, replaces it with a symbolic link pointing to the target MCM container path, and sends an XPC query to containermanagerd with:
   • class = 7 (App Group)
   • group_identifiers = <app’s own signed App Group>
   • part = 3 (Library/Caches)
   • partDomain = "" (empty string: bypassing the 27.2 partDomain checks)
   • flags = 0x8100000000 (return path + issue read/write sandbox extension type 3)
4. containermanagerd constructs <app group>/Library/Caches, resolves the symlink to the target container, and issues a valid sandbox extension token for the resolved path.
5. The app calls sandbox_extension_consume() to gain read/write access, then immediately removes the symlink and restores the original Library/Caches folder.

Reachable MCM container paths

Container enumeration: LaunchServices DB vs fsgetpath inode scan

Because iOS sandbox rules prevent listing the parent directories (such as /var/mobile/Containers/Data/Application) directly, tools need a way to discover each container’s UUID folder name:

• fsgetpath brute-force inode scan (used by KAMUI, Regitela’s pathleak, and WQFiles v0.1–v0.7): Calls fsgetpath() across inode numbers on the data volume until container directories are found. On a heavily used device, the first scan can take several minutes (and up to an hour on iOS 26).
• LaunchServices database lookup (introduced in WQFiles v0.8): WQFiles locates lsd’s container among recent inodes within seconds, reads the system LaunchServices database directly, and extracts the exact container paths, bundle IDs, and localized names for all App Data, App Groups, and Extension Data without waiting for a full-volume inode scan.