diff --git a/src/binary-exploitation/common-binary-protections-and-bypasses/memory-tagging-extension-mte.md b/src/binary-exploitation/common-binary-protections-and-bypasses/memory-tagging-extension-mte.md index b55afad373f..de5518f64f0 100644 --- a/src/binary-exploitation/common-binary-protections-and-bypasses/memory-tagging-extension-mte.md +++ b/src/binary-exploitation/common-binary-protections-and-bypasses/memory-tagging-extension-mte.md @@ -89,6 +89,56 @@ prctl(PR_SET_TAGGED_ADDR_CTRL, On Android, stack tagging is not automatic for arbitrary native code: if a lab or target was compiled with **`-fsanitize=memtag`** and a **`-fsanitize-memtag-mode=sync`** link mode, stack bugs that would normally stay invisible to heap-only MTE may now fault reliably. For a concrete exploitation scenario where MTE can break the overflow stage before shellcode/ROP, check [the ARM64 stack shellcode notes](../stack-overflow/stack-shellcode/stack-shellcode-arm64.md). +### iOS / iPadOS MIE recon and crash triage + +Apple's **Memory Integrity Enforcement (MIE)** combines secure typed allocators, synchronous EMTE, and tag-confidentiality controls. On supported hardware, third-party targets opt in from Xcode's **Enhanced Security → Memory Safety → Enable Hardware Memory Tagging** setting.[[7]](#references)[[8]](#references) + +Current Apple SDK documentation identifies the main Boolean entitlement as **`com.apple.security.hardened-process.checked-allocations`** and requires the parent hardened-process and enhanced-security-version entitlements. The soft-mode key is **`com.apple.security.hardened-process.checked-allocations.soft-mode`**; when true, violations generate simulated-crash diagnostics instead of terminating the process. The 8kSec sample instead reports **`com.apple.security.cs.checked_allocations`**; audit both spellings when examining binaries from different SDK/toolchain revisions, but require an actual Boolean `true` value rather than merely grepping for `checked_allocations`.[[7]](#references)[[9]](#references) + +Resolve the bundle executable from `Info.plist`, dump its signed entitlements, and parse the Boolean values explicitly:[[7]](#references)[[9]](#references) + +```bash +APP=/path/to/Target.app +EXE=$(/usr/libexec/PlistBuddy -c 'Print :CFBundleExecutable' "$APP/Info.plist") +ENT=$(mktemp) +codesign -d --entitlements :- "$APP/$EXE" 2>/dev/null > "$ENT" +for KEY in com.apple.security.hardened-process.checked-allocations \ + com.apple.security.hardened-process.checked-allocations.soft-mode \ + com.apple.security.cs.checked_allocations; do + VALUE=$(/usr/libexec/PlistBuddy -c "Print :$KEY" "$ENT" 2>/dev/null) || continue + printf '%s = %s\n' "$KEY" "$VALUE" +done +rm -f "$ENT" +``` + +The entitlement proves that the signed target requested the feature, **not** that checks were active at runtime: Apple states that the setting has no effect on unsupported hardware. For hard-fault testing, use a supported physical device, ensure the soft-mode entitlement is absent/false, and execute the spatial and temporal tests separately because the first detected violation should terminate the process.[[7]](#references)[[9]](#references) + +```c +#include +#include + +__attribute__((noinline, optnone)) void mie_oob(void) { + char *p = malloc(16); + memset(p, 'A', 32); // crosses the first 16-byte granule +} + +__attribute__((noinline, optnone)) void mie_uaf(void) { + volatile char *p = malloc(32); + free((void *)p); + p[0] = 'X'; // stale pointer after allocator retagging +} +``` + +These are destructive probes, not deterministic feature detectors: the invalid access must reach a differently tagged granule, and the four-bit tag space permits collisions. Treat a matching crash as strong runtime confirmation, but do not treat one non-crashing attempt as proof that MIE is disabled.[[9]](#references) + +For iOS `.ips` triage, the high-signal runtime fields observed in a synchronous MIE failure are:[[9]](#references) + +- `exception.type = EXC_GUARD` with subtype `GUARD_TYPE_VIRT_MEMORY`. +- Flavor `GUARD_EXC_MTE_SYNC_FAULT`, which distinguishes the event from an ordinary `EXC_BAD_ACCESS`. +- `mteState = enabled`, which confirms tagging was active at the fault. +- `mtePageTags`, containing nearby 4-bit allocation tags, plus the tagged fault address in the exception codes. +- The triggered thread's first application frame: synchronous enforcement stops the invalid load/store at the corruption point, so a frame such as `_platform_memset` above the caller usually identifies the actual overflowing operation. + ## Implementation & Detection Examples Linux calls its MTE-backed kernel memory-safety detector **Hardware Tag-Based KASAN**. Supported kernel allocators such as `kmalloc` assign an allocation tag to the memory and return a pointer carrying the corresponding logical tag.[[5]](#references) @@ -134,6 +184,20 @@ Project Zero's MTE testing/use-case analysis is still a good mental model:[ This is especially relevant for browser, IPC and kernel exploits where the attacker can try to keep the whole corruption chain inside one "quiet" execution window. +### Stale PFN and device aliases + +MTE checks do not repair lifetime bugs in page mappings. If a driver leaves an untagged or differently governed alias writable after returning the physical page to an allocator, the page can be recycled for a protected object while the stale alias still modifies the same bytes. This bypass class avoids guessing the new allocation tag because the corrupting path never performs the expected tagged dereference.[[6]](#references) + +The CVE-2025-0072 exploit demonstrated the following concrete pattern in the Arm Mali CSF driver:[[6]](#references) + +1. Bind a queue and map its command user pages into userspace. +2. Unbind/rebind the queue so new pages overwrite `queue->phys`. +3. Unmap the old region; cleanup frees the *new* pages while their second userspace mapping survives. +4. Groom a freed page into a Mali GPU page-table global directory (PGD). +5. Rewrite the recycled PGD through the stale userspace PFN mapping, then map arbitrary kernel memory for read/write and code execution. + +The demonstrated access was through a driver-created **userspace mapping** backed by `insert_pfn`, not a GPU write through an old GPU mapping. The broader lesson still applies to GPU/DMA aliases: CPU-side tag checks cannot compensate for stale writable mappings or non-CPU agents that do not participate in the same tag-checking domain. Drivers must revoke every CPU and device mapping before page reuse and synchronize IOMMU/page-table teardown with allocator lifetime.[[6]](#references)[[9]](#references) + ### Speculative Tag Leakage (TikTag) *TikTag* (2024) demonstrated two speculative execution gadgets (**TIKTAG-v1/v2**) able to leak the 4-bit allocation tag of arbitrary addresses with **>95% success** in **less than 4 seconds**. The key idea is to speculatively trigger a tag-checked access, use a cache side channel to learn whether the access matched, and iterate over candidate tags until the correct one is recovered.[[3]](#references) @@ -154,5 +218,9 @@ The paper demonstrates this against **Google Chrome** and the **Linux kernel**.< - [3] [TikTag: Breaking ARM's Memory Tagging Extension with Speculative Execution](https://arxiv.org/abs/2406.08719) - [4] [Sticky Tags: Efficient and Deterministic Spatial Memory Error Mitigation using Persistent Memory Tags](https://www.vusec.net/projects/stickytags/) - [5] [Linux kernel documentation - Kernel Address Sanitizer (KASAN)](https://docs.kernel.org/dev-tools/kasan.html) +- [6] [GitHub Security Lab - Bypassing MTE with CVE-2025-0072](https://github.blog/security/vulnerability-research/bypassing-mte-with-cve-2025-0072/) +- [7] [Apple Developer - Enabling enhanced security for your app](https://developer.apple.com/documentation/xcode/enabling-enhanced-security-for-your-app) +- [8] [Apple Security Research - Memory Integrity Enforcement](https://security.apple.com/blog/memory-integrity-enforcement/) +- [9] [8kSec - MIE Deep Dive Part 2: Enabling Apps and Analyzing Memory-Tagging Crashes](https://8ksec.io/mie-deep-dive-enabling-apps) {{#include ../../banners/hacktricks-training.md}} diff --git a/src/mobile-pentesting/ios-pentesting/README.md b/src/mobile-pentesting/ios-pentesting/README.md index c5f13dad964..92c534a6894 100644 --- a/src/mobile-pentesting/ios-pentesting/README.md +++ b/src/mobile-pentesting/ios-pentesting/README.md @@ -42,6 +42,8 @@ Some interesting iOS - IPA files decompilers: - [https://github.com/LaurieWired/Malimite](https://github.com/LaurieWired/Malimite) - [https://ghidra-sre.org/](https://ghidra-sre.org/) +For iOS Memory Integrity Enforcement discovery and synchronous tag-fault triage, see [Memory Tagging Extension (MTE)](../../binary-exploitation/common-binary-protections-and-bypasses/memory-tagging-extension-mte.md).[[31]](#references) + It's recommended to use the tool [**MobSF**](https://github.com/MobSF/Mobile-Security-Framework-MobSF) to perform an automatic Static Analysis to the IPA file. Identification of **protections are present in the binary**: @@ -1250,5 +1252,6 @@ zero-click-messaging-image-parser-chains.md - [28] [Mobile Pentesting 101 – Bypassing Biometric Authentication](https://securitycafe.ro/2022/09/05/mobile-pentesting-101-bypassing-biometric-authentication/) - [29] [OWASP MASTG – iOS Testing Cryptography](https://mas.owasp.org/MASTG/0x06e-Testing-Cryptography/) - [30] [iOS (Swift) Anti-Jailbreak Bypass Using Frida – syrion (Internet Archive)](https://web.archive.org/web/20200514192843/https://syrion.me/blog/ios-swift-antijailbreak-bypass-frida/) +- [31] [8kSec - MIE Deep Dive Part 2: Enabling Apps and Analyzing Memory-Tagging Crashes](https://8ksec.io/mie-deep-dive-enabling-apps) {{#include ../../banners/hacktricks-training.md}} diff --git a/src/mobile-pentesting/ios-pentesting/extracting-entitlements-from-compiled-application.md b/src/mobile-pentesting/ios-pentesting/extracting-entitlements-from-compiled-application.md index 4117bf222e7..e5dbf7f628d 100644 --- a/src/mobile-pentesting/ios-pentesting/extracting-entitlements-from-compiled-application.md +++ b/src/mobile-pentesting/ios-pentesting/extracting-entitlements-from-compiled-application.md @@ -9,6 +9,8 @@ codesign -d --entitlements :- "Payload/Target.app" 2>/dev/null security cms -D -i "Payload/Target.app/embedded.mobileprovision" ``` +For MIE-specific entitlement interpretation, validation tests, and `.ips` crash signatures, see [Memory Tagging Extension (MTE)](../../binary-exploitation/common-binary-protections-and-bypasses/memory-tagging-extension-mte.md).[[4]](#references) + ### **Extracting Entitlements and Mobile Provision Files** An IPA or installed app may not contain a standalone `.entitlements` file. Effective signed entitlements are embedded in the Mach-O code signature, while `embedded.mobileprovision`—when present—contains the provisioning profile and its permitted entitlement set. These are related but not guaranteed to be identical. @@ -55,5 +57,6 @@ Adjusting the `-A num, --after-context=num` flag allows for the display of more - [1] [MASTG-TEST-0069: Review entitlements embedded in the compiled app binary - OWASP MASTG](https://mas.owasp.org/MASTG/tests/ios/MASVS-PLATFORM/MASTG-TEST-0069/#review-entitlements-embedded-in-the-compiled-app-binary) - [2] [Apple — Code Signing Guide: Code Signing Tasks](https://developer.apple.com/library/archive/documentation/Security/Conceptual/CodeSigningGuide/Procedures/Procedures.html) - [3] [Telegram-iOS entitlement file used in the example](https://github.com/peter-iakovlev/Telegram-iOS/blob/77ee5c4dabdd6eb5f1e2ff76219edf7e18b45c00/Telegram-iOS/Telegram-iOS-AppStoreLLC.entitlements) +- [4] [8kSec - MIE Deep Dive Part 2: Enabling Apps and Analyzing Memory-Tagging Crashes](https://8ksec.io/mie-deep-dive-enabling-apps) {{#include ../../banners/hacktricks-training.md}}