From 1557f8ff526eae1623c3a94b27b801749c22ce0c Mon Sep 17 00:00:00 2001 From: Translator Date: Mon, 29 Sep 2025 09:00:33 +0000 Subject: [PATCH] Translated ['', 'src/binary-exploitation/ios-exploiting/ios-physical-uaf --- .../ios-physical-uaf-iosurface.md | 112 +++++++++--------- 1 file changed, 56 insertions(+), 56 deletions(-) diff --git a/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md b/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md index b74e61bc4..430c132aa 100644 --- a/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md +++ b/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md @@ -1,99 +1,99 @@ -# iOS Physical Use-After-Free via IOSurface +# iOS Physical Use After Free via IOSurface {{#include ../../banners/hacktricks-training.md}} ## Physical use-after-free -Dit is 'n opsomming van die pos by [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html). Boonop is verdere inligting oor exploits wat hierdie tegniek gebruik te vinde by [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd) +Dit is 'n opsomming van die pos by [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html). Verder kan meer inligting oor exploits wat hierdie tegniek gebruik gevind word by [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd) -### Memory management in XNU +### Geheuebestuur in XNU -Die virtuele geheue-adresruimte vir gebruikersprosesse op iOS strek van **0x0 tot 0x8000000000**. Hierdie adresse kaart egter nie direk na fisiese geheue nie. In plaas daarvan gebruik die kernel **page tables** om virtuele adresse na werklike **fisiese adresse** te vertaal. +Die **virtual memory address space** vir gebruikersprosesse op iOS strek van **0x0 to 0x8000000000**. Hierdie adresse kaart egter nie direk na fisiese geheue nie. In plaas daarvan gebruik die **kernel** **page tables** om virtuele adresse na werklike **physical addresses** te vertaal. #### Levels of Page Tables in iOS Page tables is hiërargies georganiseer in drie vlakke: 1. **L1 Page Table (Level 1)**: -* Elke inskrywing hier verteenwoordig 'n groot reikafstand van virtuele geheue. -* Dit dek **0x1000000000 bytes** (of **256 GB**) van virtuele geheue. +* Elke inskrywing hier verteenwoordig 'n groot gebied van virtuele geheue. +* Dit dek **0x1000000000 bytes** (of **256 GB**) virtuele geheue. 2. **L2 Page Table (Level 2)**: * 'n Inskrywing hier verteenwoordig 'n kleiner streek van virtuele geheue, spesifiek **0x2000000 bytes** (32 MB). -* 'n L1-inskrywing kan na 'n L2-tabel wys as dit nie die hele streek self kan karteer nie. +* 'n L1-inskrywing kan na 'n L2-table wys as dit nie die hele streek self kan map nie. 3. **L3 Page Table (Level 3)**: -* Dit is die fynste vlak, waar elke inskrywing 'n enkele **4 KB** geheuebladsy karteer. -* 'n L2-inskrywing kan na 'n L3-tabel wys as meer gedetailleerde beheer nodig is. +* Dit is die fynste vlak, waar elke inskrywing 'n enkele **4 KB** geheuebladsy map. +* 'n L2-inskrywing kan na 'n L3-table wys indien meer gedetailleerde beheer benodig word. #### Mapping Virtual to Physical Memory * **Direct Mapping (Block Mapping)**: -* Sommige inskrywings in 'n page table karteer direk 'n reeks virtuele adresse na 'n aaneenlopende reeks fisiese adresse (soort van kortpad). +* Sommige inskrywings in 'n page table map direk 'n reeks virtuele adresse na 'n aaneenlopende reeks fisiese adresse (soort van kortpad). * **Pointer to Child Page Table**: -* As fynere beheer nodig is, kan 'n inskrywing in een vlak (bv. L1) na 'n **child page table** op die volgende vlak (bv. L2) wys. +* As fynere beheer benodig word, kan 'n inskrywing op een vlak (bv. L1) na 'n child page table op die volgende vlak (bv. L2) wys. #### Example: Mapping a Virtual Address Kom ons sê jy probeer toegang kry tot die virtuele adres **0x1000000000**: 1. **L1 Table**: -* Die kernel kyk na die L1 page table-inskrywing wat ooreenstem met hierdie virtuele adres. As dit 'n **pointer to an L2 page table** bevat, gaan dit na daardie L2-tabel. +* Die kernel kyk na die L1 page table inskrywing wat ooreenstem met hierdie virtuele adres. As dit 'n **pointer to an L2 page table** het, gaan dit na daardie L2-table. 2. **L2 Table**: -* Die kernel kyk die L2 page table vir 'n meer gedetailleerde kartering. As hierdie inskrywing na 'n **L3 page table** wys, gaan dit daarheen. +* Die kernel kyk die L2 page table na vir 'n meer gedetailleerde mapping. As hierdie inskrywing na 'n **L3 page table** wys, gaan dit verder daarheen. 3. **L3 Table**: -* Die kernel soek die finale L3-inskrywing, wat na die **fisiese adres** van die werklike geheuebladsy wys. +* Die kernel soek die finale L3-inskrywing, wat na die **physical address** van die werklike geheuebladsy wys. #### Example of Address Mapping -As jy die fisiese adres **0x800004000** in die eerste indeks van die L2-tabel skryf, dan: +As jy die fisiese adres **0x800004000** in die eerste indeks van die L2-table skryf, dan: -* Virtuele adresse van **0x1000000000** tot **0x1002000000** karteer na fisiese adresse van **0x800004000** tot **0x802004000**. +* Virtuele adresse van **0x1000000000** tot **0x1002000000** map na fisiese adresse van **0x800004000** tot **0x802004000**. * Dit is 'n **block mapping** op die L2-vlak. -Alternatiewelik, as die L2-inskrywing na 'n L3-tabel wys: +Alternatiewelik, as die L2-inskrywing na 'n L3-table wys: -* Elke 4 KB-bladsy in die virtuele adresreeks **0x1000000000 -> 0x1002000000** sou deur individuele inskrywings in die L3-tabel gekarteer word. +* Elke 4 KB-bladsy in die virtuele adresreeks **0x1000000000 -> 0x1002000000** sou deur individuele inskrywings in die L3-table gemap word. ### Physical use-after-free -'n **Physical use-after-free** (UAF) gebeur wanneer: +'N **physical use-after-free** (UAF) gebeur wanneer: -1. 'n Proses **alloceer** sekere geheue as **readable and writable**. -2. Die **page tables** word opgedateer om hierdie geheue na 'n spesifieke fisiese adres te karteer wat die proses kan toegang. -3. Die proses **dealloceer** (vry) die geheue. -4. Weens 'n **bug**, vergeet die kernel egter om die kartering uit die page tables te verwyder, al merk dit die ooreenstemmende fisiese geheue as vry. -5. Die kernel kan dan hierdie "vrygemaakte" fisiese geheue **heralloceer** vir ander doeleindes, soos **kernel data**. -6. Aangesien die kartering nie verwyder is nie, kan die proses steeds **lees en skryf** na daardie fisiese geheue. +1. 'n proses sekere geheue **alloceer** as **leesbaar en skryfbaar**. +2. Die **page tables** word opgedateer om hierdie geheue na 'n spesifieke fisiese adres te map wat die proses kan benader. +3. Die proses **dealloceer** (vrylaat) die geheue. +4. Weens 'n **fout**, vergeet die kernel om die mapping uit die page tables te verwyder, selfs al merk dit die ooreenstemmende fisiese geheue as vry. +5. Die kernel kan dan hierdie “vrygemaakte” fisiese geheue weer **herallokeer** vir ander doeleindes, soos **kernel data**. +6. Aangesien die mapping nie verwyder is nie, kan die proses steeds na hierdie fisiese geheue **lees en skryf**. -Dit beteken die proses kan toegang hê tot **bladsye van kernel memory**, wat sensitiewe data of strukture kan bevat, en moontlik 'n aanvaller toelaat om **kernel memory te manipuleer**. +Dit beteken die proses kan toegang tot **bladsye van kernel-geheue** kry, wat sensitiewe data of strukture kan bevat, en moontlik 'n aanvaller toelaat om **kernel memory** te manipuleer. ### IOSurface Heap Spray -Aangesien die aanvaller nie kan beheer watter spesifieke kernel-bladsye aan vrygemaakte geheue toegeken sal word nie, gebruik hulle 'n tegniek genaamd **heap spray**: +Aangesien die aanvaller nie kan beheer watter bepaalde kernel-bladsye aan vrygemaakte geheue toegewys sal word nie, gebruik hulle 'n tegniek genaamd **heap spray**: -1. Die aanvaller **skep 'n groot aantal IOSurface objects** in kernel memory. +1. Die aanvaller **skep 'n groot aantal IOSurface objects** in kernel-geheue. 2. Elke IOSurface-object bevat 'n **magic value** in een van sy velde, wat dit maklik maak om te identifiseer. -3. Hulle **scan die vrygemaakte bladsye** om te sien of enige van hierdie IOSurface-objects op 'n vrygemaakte bladsy geland het. -4. Wanneer hulle 'n IOSurface-object op 'n vrygemaakte bladsy vind, kan hulle dit gebruik om **kernel memory te lees en skryf**. +3. Hulle **skandeer die vrygemaakte bladsye** om te sien of enige van hierdie IOSurface-objekte op 'n vrygemaakte bladsy geland het. +4. Wanneer hulle 'n IOSurface-object op 'n vrygemaakte bladsy vind, kan hulle dit gebruik om **kernel memory** te lees en te skryf. -Meer inligting hieroor by [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups) +Meer inligting daaroor by [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups) > [!TIP] -> Wees bewus dat iOS 16+ (A12+) toestelle hardeware-mitigasies bring (soos PPL of SPTM) wat physical UAF-tegnieke baie minder lewensvatbaar maak. -> PPL afdwing streng MMU-beskermings op bladsye wat verband hou met code signing, entitlements, en sensitiewe kernel data, so selfs as 'n bladsy hergebruik word, word skryfoperasies vanaf userland of gekompromitteerde kernel-kode na PPL-beskermde bladsye geblokkeer. -> Secure Page Table Monitor (SPTM) brei PPL uit deur page table-updates self te verhinder. Dit verseker dat selfs bevoorregte kernel-kode nie stilweg vrygemaakte bladsye kan herkarreer of mappings kan verander sonder deur veilige kontroles te gaan nie. -> KTRR (Kernel Text Read-Only Region) sluit die kernel se kodesegment na opstart as read-only. Dit voorkom enige runtime-wysigings aan kernel-kode en sluit 'n groot aanvalsvlak wat physical UAF-exploits dikwels benut, af. -> Verder is IOSurface-allocations minder voorspelbaar en moeiliker om in user-accessible areas te karteer, wat die “magic value scanning”-truuk baie minder betroubaar maak. En IOSurface is nou beskerm deur entitlements en sandbox-restriksies. +> Wees bewus dat iOS 16+ (A12+) toestelle hardeware-mitigasies bring (soos PPL of SPTM) wat physical UAF-tegnieke baie minder uitvoerbaar maak. +> PPL handhaaf streng MMU-beskerming op bladsye wat verband hou met code signing, entitlements, en sensitiewe kernel-data, so selfs as 'n bladsy weer gebruik word, word skrywe vanaf userland of gekompromitteerde kernel-kode na PPL-beskermde bladsye geblokkeer. +> Secure Page Table Monitor (SPTM) brei PPL uit deur page table updates self te verharden. Dit verseker dat selfs bevoorregte kernel-kode nie stilweg vrygemaakte bladsye kan herkaart of mappings kan manipuleer sonder om deur sekure kontrole te gaan nie. +> KTRR (Kernel Text Read-Only Region) vergrendel die kernel se code-afdeling as read-only na opstart. Dit voorkom enige runtime-wysigings aan kernel-kode en sluit 'n groot aanvalsvlak af waarop physical UAF-exploits dikwels staatmaak. +> Boonop is `IOSurface`-allokasies minder voorspelbaar en moeiliker om in user-accessible streke te map, wat die “magic value scanning”-truuk minder betroubaar maak. En `IOSurface` word nou ook deur entitlements en sandbox-restriksies beskerm. ### Step-by-Step Heap Spray Process -1. **Spray IOSurface Objects**: Die aanvaller skep baie IOSurface-objects met 'n spesiale identifiseerder ("magic value"). -2. **Scan Freed Pages**: Hulle kontroleer of enige van die objects op 'n vrygemaakte bladsy toegeken is. -3. **Read/Write Kernel Memory**: Deur velde in die IOSurface-object te manipuleer, kry hulle die vermoë om **arbitrary reads and writes** in kernel memory uit te voer. Dit laat hulle toe om: -* Een veld te gebruik om **enige 32-bit waarde** in kernel memory te lees. -* 'n Ander veld te gebruik om **64-bit waardes te skryf**, waarmee 'n stabiele **kernel read/write primitive** bereik word. +1. **Spray IOSurface Objects**: Die aanvaller skep baie IOSurface-objekte met 'n spesiale identifiseerder ("magic value"). +2. **Scan Freed Pages**: Hulle kyk of enige van die objekte op 'n vrygemaakte bladsy toegeken is. +3. **Read/Write Kernel Memory**: Deur velde in die IOSurface-object te manipuleer, verkry hulle die vermoë om **arbitrary reads and writes** in kernel-geheue uit te voer. Dit laat hulle toe om: +* Een veld te gebruik om **enige 32-bit waarde** in kernel-geheue te lees. +* 'n Ander veld te gebruik om **64-bit waardes** te skryf, en sodoende 'n stabiele **kernel read/write primitive** te bereik. -Generate IOSurface objects with the magic value IOSURFACE\_MAGIC to later search for: +Genereer IOSurface objects met die magic value IOSURFACE\_MAGIC om later daarna te soek: ```c void spray_iosurface(io_connect_t client, int nSurfaces, io_connect_t **clients, int *nClients) { if (*nClients >= 0x4000) return; @@ -114,7 +114,7 @@ io_connect_t id = result.surface_id; } } ``` -Soek na **`IOSurface`**-objekte in 'n vrygemaakte fisiese bladsy: +Soek na **`IOSurface`**-voorwerpe in 'n vrygestelde fisiese bladsy: ```c int iosurface_krw(io_connect_t client, uint64_t *puafPages, int nPages, uint64_t *self_task, uint64_t *puafPage) { io_connect_t *surfaceIDs = malloc(sizeof(io_connect_t) * 0x4000); @@ -148,25 +148,25 @@ free(surfaceIDs); return 0; } ``` -### Bereik Kernel Read/Write met IOSurface +### Bereiking van Kernel Read/Write met IOSurface -Nadat ons beheer oor 'n IOSurface-objek in kernel memory (gemap na 'n vrygemaakte fisiese bladsy wat vanaf userspace toeganklik is) bereik het, kan ons dit gebruik vir arbitrêre kernel read and write operations. +Nadat ons beheer oor 'n IOSurface-object in kernel memory bereik het (gemapped na 'n vrygestelde fisiese bladsy wat vanaf userspace toeganklik is), kan ons dit gebruik vir **arbitrary kernel read and write operations**. **Key Fields in IOSurface** -Die IOSurface-objek het twee belangrike velde: +Die IOSurface-object het twee belangrike velde: -1. **Use Count Pointer**: Laat 'n **32-bit read** toe. -2. **Indexed Timestamp Pointer**: Laat 'n **64-bit write** toe. +1. **Use Count Pointer**: Maak 'n **32-bit read** moontlik. +2. **Indexed Timestamp Pointer**: Maak 'n **64-bit write** moontlik. -Deur hierdie pointers oor te skryf, herlei ons hulle na arbitrêre adresse in kernel memory, wat read/write-vaardighede moontlik maak. +Deur hierdie pointers oor te skryf, herlei ons hulle na willekeurige adresse in kernel memory en skep ons read/write-vermoëns. #### 32-Bit Kernel Read Om 'n read uit te voer: 1. Oorskryf die **use count pointer** sodat dit na die teikenadres minus 'n 0x14-byte offset wys. -2. Gebruik die `get_use_count` method om die waarde by daardie adres te read. +2. Gebruik die `get_use_count`-metode om die waarde by daardie adres te read. ```c uint32_t get_use_count(io_connect_t client, uint32_t surfaceID) { uint64_t args[1] = {surfaceID}; @@ -184,12 +184,12 @@ iosurface_set_use_count_pointer(info.object, orig); return value; } ``` -#### 64-Bit Kernel Write +#### 64-bis kernskryf Om 'n skryf uit te voer: 1. Oorskryf die **indexed timestamp pointer** na die teikenadres. -2. Gebruik die `set_indexed_timestamp` metode om 'n 64-bit-waarde te skryf. +2. Gebruik die `set_indexed_timestamp` metode om 'n 64-bis waarde te skryf. ```c void set_indexed_timestamp(io_connect_t client, uint32_t surfaceID, uint64_t value) { uint64_t args[3] = {surfaceID, 0, value}; @@ -206,10 +206,10 @@ iosurface_set_indexed_timestamp_pointer(info.object, orig); #### Exploit Flow Opsomming 1. **Trigger Physical Use-After-Free**: Vrye bladsye is beskikbaar vir hergebruik. -2. **Spray IOSurface Objects**: Allokeer baie IOSurface objects met 'n unieke "magic value" in kernel memory. -3. **Identify Accessible IOSurface**: Lokaliseer 'n IOSurface op 'n vrygemaakte bladsy wat jy beheer. -4. **Abuse Use-After-Free**: Wysig pointers in die IOSurface object om arbitraire **kernel read/write** via IOSurface-metodes moontlik te maak. +2. **Spray IOSurface Objects**: Ken baie IOSurface objects toe met 'n unieke "magic value" in kernel memory. +3. **Identify Accessible IOSurface**: Lokaliseer 'n IOSurface op 'n vrygestelde bladsy wat jy beheer. +4. **Abuse Use-After-Free**: Wysig pointers in die IOSurface object om arbitrêre **kernel read/write** via IOSurface methods moontlik te maak. -Met hierdie primitiewe verskaf die exploit beheerde **32-bit reads** en **64-bit writes** na kernel memory. Verdere jailbreak-stappe kan meer stabiele read/write primitiewe behels, wat mag vereis dat addisionele beskermings omseil word (bv. PPL op nuwer arm64e devices). +Met hierdie primitives verskaf die exploit beheerde **32-bit reads** en **64-bit writes** na kernel memory. Verdere jailbreak-stappe kan meer stabiele read/write primitives vereis, wat die omseiling van addisionele beskermings mag insluit (bv. PPL op nuwer arm64e-toestelle). {{#include ../../banners/hacktricks-training.md}}