Sfruttamento in 10.15 e 11.0 beta

Il runtime Objective-C utilizzato in macOS 10.15 non è vulnerabile alla tecnica di sfruttamento descritta in precedenza, perché le categorie non vengono caricate prima che didCallDyldNotifyRegister sia impostato, facendo sì che il nostro metodo +initialize venga chiamato solo dopo l'inizializzazione del sandbox.

Tuttavia, map_images viene ancora chiamato sul nostro binario, rendendo possibile alterare i dati del runtime in modi non previsti che ci permetterebbero di eseguire codice prima dell'inizializzazione del sandbox. Lo sfruttamento completo e commentato si trova in main.c, ma qui illustrerò i dettagli di base. Creiamo una struttura di classe Objective-C il cui puntatore data punta a una posizione in libxbc.dylib. Tale posizione deve essere scelta in modo che flags abbia il bit 31 (RW_REALIZED) impostato, così il runtime non tenterà di realizzare questa classe invalida e crashare, e firstSubclass deve condividere il suo indirizzo con l'isa di una classe che vogliamo sovrascrivere. Un'altra (meta) classe erediterà da questa classe invalida e fornirà il proprio metodo +initialize. Aggiungiamo la sottoclasse a __objc_nlclslist in modo che il runtime realizzi questa classe.

Quando il runtime realizza la nostra sottoclasse, cosa che avviene prima dell'inizializzazione del sandbox, chiamerà addSubclass sulla nostra superclasse invalida e sulla sottoclasse, il che sostituirà l'isa della vittima con un puntatore alla nostra sottoclasse, effettivamente sostituendo tutti i suoi metodi con il nostro +initialize. Quando il nostro metodo +initialize viene chiamato, cosa che avverrà prima dell'inizializzazione del sandbox se abbiamo scelto una classe vittima adatta, possiamo nuovamente sostituire i riferimenti a _libsecinit_initializer con nop (condizionalmente o meno), e correggere le modifiche al runtime che abbiamo fatto per riprendere l'esecuzione senza crash successivi.

Demo fornita

La demo fornita può essere compilata eseguendo make, creando un file in ~/Documents/SecretDocument.txt ed eseguendo SnatchBox.app/Contents/MacOS/SnatchBox dal terminale (viene creato un bundle perché richiesto da com.apple.security.app-sandbox, ma questo è comunque un programma da riga di comando). Il binario compilato è firmato con com.apple.security.app-sandbox che normalmente impedirebbe l'accesso a ~/Documents/SecretDocument.txt (poiché non si trova nel nostro contenitore), ma sarà comunque in grado di leggere i suoi dati. A causa di modifiche alla struttura del runtime, questa demo non funzionerà su macOS 10.14 e versioni precedenti non modificate, ma funzionerà su 10.15 e 11.0 (Testato: 10.15.4, 10.15.7 e 11.0 Beta (20A5354i)). Le due tecniche di sfruttamento possono essere combinate per colpire entrambe le versioni del runtime, ma tale dimostrazione non è fornita.

Example run:

Impatto

Come menzionato in precedenza, ciò permette di creare un'applicazione del Mac App Store che non viene eseguita in un sandbox nonostante sia richiesto dalla politica dell'App Store. La vulnerabilità può anche essere utilizzata in un framework, che può essere usato da applicazioni App Store altrimenti legittime. Infine, può persino essere combinata con qualcosa di simile a "Xcode Ghost" per iniettare in massa codice dannoso che viene eseguito al di fuori del sandbox nelle applicazioni App Store.

Correzione

Apple ha corretto lo sfruttamento durante la fase di beta testing di macOS 11.0 aggiungendo una chiamata a malloc_size in realizeClassWithoutSwift. Questo conferma che se una classe è marcata come realizzata (RW_REALIZED, come la nostra classe fittizia), ha effettivamente un puntatore dati valido, allocato con malloc, con la dimensione corretta (0x20 byte). Se non è così, il runtime si interromperà con un messaggio simile a realized class 0x100002078 has corrupt data pointer 0x7fff88c00948. La correzione è stata applicata anche a iOS, iPadOS, tvOS e watchOS; anche se non direttamente colpiti.