Triple_fetch

triple_fetch - ianbeer [https://bugs.chromium.org/p/project-zero/issues/detail?id=1247]

Questa è un exploit per CVE-2017-7047, un errore logico in libxpc che consentiva a mittenti di messaggi malintenzionati di inviare oggetti xpc_data supportati da memoria condivisa. I consumatori di messaggi xpc non sembravano aspettarsi che i buffer di supporto degli oggetti xpc_data potessero essere modificati dal mittente mentre venivano elaborati dal destinatario.

Questo progetto sfrutta CVE-2017-7047 per costruire uno stub proof-of-concept di debugserver remoto lldb in grado di agganciarsi e consentire il debug remoto di tutti i processi in spazio utente su iOS.

Questa è una panoramica ad alto livello dell'exploit; un'analisi approfondita potrebbe seguire in una data successiva. Per ora consulta il codice per ulteriori dettagli :)

Parte I

L'exploit prende di mira NSXPC, un'implementazione Objective-C di Remote Procedure Call usata da molti servizi iOS (1). Un messaggio NSXPC consiste in un oggetto bplist16 serializzato all'interno di un oggetto xpc_data serializzato xpc all'interno di un messaggio mach.

Tra le altre cose, l'oggetto bplist16 contiene una stringa di codifica dei tipi Objective-C (2) che verrà analizzata dalla funzione ___NSMS1 in CoreFoundation. Questa funzione non si aspetta che il contenuto della stringa che sta analizzando cambi e questo exploit sfrutta questo comportamento per costruire una primitiva di overflow della heap sfruttando il fatto che una certa parte della stringa viene letta dalla memoria tre volte. Alternando tre valori diversi, scelti con cura, siamo in grado di provocare un overflow oltre una dimensione di allocazione heap scelta con byte arbitrari.

minibplist16.c contiene un'implementazione minima della serializzazione bplist e una discussione su come funziona.

Il messaggio xpc esterno contiene l'heap groom. Usa un'implementazione personalizzata del protocollo di serializzazione XPC per preparare la heap creando dizionari xpc con chiavi in collisione, così da costruire primitive di allocazione e deallocazione. Il messaggio xpc esterno contiene anche uno heap spray (usando più copie di un oggetto di memoria condivisa per mantenere basso l'uso della memoria) e uno spray di nomi di send right di mach port.

L'overflow punta il puntatore isa Class di un oggetto Objective-C a un oggetto fittizio creato tramite heap spray, così che quando un metodo viene chiamato su quell'oggetto fittizio lo stack viene spostato su una piccola ROP stack. La ROP esegue un brute force tra i nomi dei send right di mach port spruzzati, cercando di inviare il send right del bersaglio al proprio task port a ciascuno dei nomi candidati di send right spruzzati. L'exploit resta in ascolto su tutte le porte spruzzate e, se ha successo, riceve un send right al task port del bersaglio, a quel punto ha il pieno controllo del task bersaglio.

Interludio

L'exploit prende di mira il servizio com.apple.CoreAuthentication.daemon ospitato dal demone coreauthd, che viene eseguito come root. Questo servizio è raggiungibile dalla sandbox dell'app. Un po' di sperimentazione dopo aver inizialmente fatto funzionare l'exploit ha rivelato che dal contesto di coreauthd l'API processor_set_tasks è in grado di ottenere send right ai task port di tutti i processi in spazio utente in esecuzione sul dispositivo. Questa è una conoscenza pubblica almeno dal 2012 e la storia è trattata in modo approfondito dal noto ricercatore di internals iOS Jonathan Levin sul suo sito (3). Il codice caricato da Levin nel 2015 funziona ancora oggi: non richiede un dispositivo jailbroken, basta root su un dispositivo di serie.

Parte II

L'obiettivo principale del debugger che volevo costruire con questo exploit era poter agganciare un processo arbitrario, impostare breakpoint e ispezionare e modificare lo stato di registri e memoria quando vengono raggiunti. Piuttosto che implementare da zero il protocollo remoto di gdb o lldb, ho deciso di apportare le modifiche necessarie al progetto debugserver di lldb e poi usare l'exploit per eseguirlo.

Invece di usare breakpoint software, che richiedono di disabilitare o aggirare la firma del codice, il debugserver è stato modificato per usare esclusivamente breakpoint hardware. ARM64 ha 16 registri per breakpoint hardware, il che significa che puoi avere al massimo 16 breakpoint attivi.

Il supporto prototipale per i breakpoint hardware ARM esisteva già nel codice di debugserver di lldb, ma serviva qualche hack per farlo funzionare. Ad esempio, ho dovuto aggiungere codice che modifica il puntatore a funzione pthread_introspection_hook nel processo in debug per farlo crashare sempre, così da poter rilevare la creazione di nuovi thread, propagare lo stato dei breakpoint hardware nei thread appena creati e continuare come se non fosse mai crashato.

Ho anche modificato il codice di attach e continue per sospendere e riprendere direttamente il task tramite task port, invece di usare ptrace e segnali.

Suggerimenti per la compilazione

Tutto dovrebbe funzionare su tutti i dispositivi iOS che eseguono da 10.0 a 10.3.2 inclusi. Ho testato su:

iPhone 7 + 10.3.2 iPod Touch + 10.1.1 iPad Mini 2 + 10.2

Ho incluso un binario debugserver precompilato che ti suggerisco di usare, ma la patch per il debugserver di lldb è inclusa anche in debugserver.diff.

Compilare il debugserver non è troppo difficile. Stavo lavorando con le seguenti revisioni git: lldb: 0db640c4cd1ec4e4c2580336fa5f53be029c5bc7 llvm: ec48fd127774a4b67c72ea7c3057b5c964375e77 clang: b6e778e0bfa2fc32f8821c6b33762f5cb6724659

Applica il debugserver.diff fornito.

Per la compilazione ti servono cmake e ninja (recenti); puoi ottenerli dai sorgenti o come binari dal tuo gestore di pacchetti Mac preferito.

(4) contiene una guida su come configurare una normale build di llvm su MacOS che potrebbe esserti utile.

Dovrai creare symlink per un gruppo di file header nel tuo iOS SDK, almeno:

xpc/ launchd.h libproc.h sys/proc_info.h sys/kern_control.h net/route.h mach/mach_vm.h mach/shared_region.h sys/ptrace.h crt_externs.h

la seguente invocazione cmake dovrebbe darti tutti gli indizi di cui hai bisogno:

cmake -G "Ninja" -DCMAKE_OSX_ARCHITECTURES="armv7;armv7s;arm64" -DCMAKE_TOOLCHAIN_FILE=../cmake/platforms/iOS.cmake -DCMAKE_BUILD_TYPE=Release -DLLVM_BUILD_RUNTIME=Off -DLLVM_INCLUDE_TESTS=Off -DLLVM_INCLUDE_EXAMPLES=Off -DLLVM_ENABLE_BACKTRACES=Off ../

ninja debugserver

Dovrai quindi firmare o falsificare la firma del binario debugserver e sostituire quello presente nel progetto xcode fornito.

Firma del codice

Il progetto dell'exploit, per impostazione predefinita, installerà una versione migliorata dell'hook amfid di mach_portal (questa volta con supporto funzionante per i file fat e senza offset hardcoded :) )

Se vuoi solo eseguire il debug, dovresti essere in grado di firmare il binario debugserver con il tuo certificato e disabilitare l'hook amfid.

Se usi l'hook amfid, tieni presente che l'app in cui è in esecuzione è ancora soggetta ai limiti di esecuzione del codice in background. L'app richiede più tempo tramite beginBackgroundTaskWithName.

Utilizzo:

Collega il tuo host e l'iDevice di destinazione alla stessa rete wireless e annota l'indirizzo IP dell'iDevice.

Compila ed esegui l'app dell'exploit. Consiglio di farlo all'interno di xcode, ma funzionerà anche in modo autonomo.

Aspetta un po'. Se non funziona dopo un paio di minuti, riavvia forzatamente il dispositivo, aspetta un po' e riprova.

Se funziona, dovrebbe stampare “patched debugserver listening on port 1234”

Se fai clic sul pulsante “get process listing” dovresti vedere l'output di ps

(è più facile vedere l'output se usi xcode, ma l'exploit mostrerà comunque l'output)

Cerca il processo di destinazione che ti interessa debuggare e annota il suo pid.

sull'host avvia lldb dalla riga di comando: $ lldb (lldb)

imposta la piattaforma su ios remote: (lldb) platform select remote-ios