bazad/xpc-string-leakCVE-2018-4248: lettura fuori dai limiti in libxpc durante la serializzazione delle stringhe.
xpc-string-leak è una prova di concetto di exploit per una lettura fuori dai limiti della memoria in libxpc. Questo exploit usa la vulnerabilità per leggere memoria heap fuori dai limiti da diagnosticd, un processo root non sandboxed con l'entitlement task_for_pid-allow.
Su macOS 10.13.5 e iOS 11.4, la funzione _xpc_string_deserialize non verifica che la stringa deserializzata abbia la lunghezza corretta prima di creare un oggetto stringa XPC con _xpc_string_create. Questo può portare a una lettura heap fuori dai limiti in stile heartbleed se la stringa XPC viene poi serializzata in un altro messaggio XPC.
Ecco l'implementazione di _xpc_string_deserialize, decompilata con IDA:
OS_xpc_string *__fastcall _xpc_string_deserialize(OS_xpc_serializer *xserializer)
{
OS_xpc_string *xstring; // rbx@1
char *string; // rax@4
char *contents; // [rsp+8h] [rbp-18h]@1
size_t size; // [rsp+10h] [rbp-10h]@1 MAPDST
xstring = 0LL;
contents = 0LL;
size = 0LL;
if ( _xpc_string_get_wire_value(xserializer, (const char **)&contents, &size) )
{
if ( contents[size - 1] || (string = _xpc_try_strdup(contents)) == 0LL )
{
xstring = 0LL;
}
else
{
xstring = _xpc_string_create(string, size - 1);
LOBYTE(xstring->flags) |= 1u;
}
}
return xstring;
}
_xpc_string_deserialize chiama prima _xpc_string_get_wire_value per ottenere un puntatore ai dati della stringa e la dimensione serializzata della stringa, come riportata dall'header della stringa. _xpc_string_deserialize verifica poi che la stringa abbia un terminatore nullo alla fine della dimensione riportata, ma, cosa cruciale, non controlla che non ci sia un terminatore nullo prima nei dati. Infine, crea una copia della stringa sull'heap e crea l'oggetto OS_xpc_string usando _xpc_string_create.
Ecco il codice decompilato di _xpc_string_create:
OS_xpc_string *__fastcall _xpc_string_create(const char *string, size_t length)
{
OS_xpc_string *xstring; // rax@1
xstring = (OS_xpc_string *)_xpc_base_create(&OBJC_CLASS___OS_xpc_string, 16LL);
if ( (((_DWORD)length + 4) & 0xFFFFFFFC) + 4 < length )
_xpc_api_misuse("Unreasonably large string");
xstring->wire_length = ((length + 4) & 0xFFFFFFFC) + 4;
xstring->string = string;
xstring->length = length;
return xstring;
}
_xpc_string_create si fida del valore di length fornito da _xpc_string_deserialize e imposta i campi appropriati nell'oggetto OS_xpc_string. A questo punto, la stringa deserializzata può avere un campo length più grande dei dati stringa allocati.
Teoricamente, questo potrebbe essere usato per innescare una corruzione di memoria in servizi che ottengono la lunghezza della stringa usando xpc_string_get_length, ma questo pattern sembra essere poco comune. Una strategia di exploit meno potente ma più pratica è far sì che la stringa venga ri-serializzata e rispedita a noi, offrendoci una finestra in stile heartbleed nella memoria del processo vittima.
Questa è l'implementazione di _xpc_string_serialize:
void __fastcall _xpc_string_serialize(OS_xpc_string *string, OS_xpc_serializer *serializer)
{
int type; // [rsp+8h] [rbp-18h]@1
int size; // [rsp+Ch] [rbp-14h]@1
type = *((_DWORD *)&OBJC_CLASS___OS_xpc_string + 10);
_xpc_serializer_append(serializer, &type, 4uLL, 1, 0, 0);
size = LODWORD(string->length) + 1;
_xpc_serializer_append(serializer, &size, 4uLL, 1, 0, 0);
_xpc_serializer_append(serializer, string->string, string->length + 1, 1, 0, 0);
}
Il parametro length di OS_xpc_string viene considerato attendibile durante la serializzazione, il che significa che molti byte vengono letti dall'heap nel messaggio serializzato. Se la stringa deserializzata era più corta della sua lunghezza riportata, il messaggio verrà riempito con dati heap fuori dai limiti.
Siamo comunque limitati allo sfruttamento di servizi XPC che riflettono parte del messaggio XPC al client, ma questo è molto più comune. Ad esempio, su macOS e iOS, diagnosticd è un candidato promettente che tra l'altro è non sandboxed, root e dispone dei privilegi task_for_pid. Diagnosticd è responsabile dell'elaborazione dei messaggi diagnostici (ad esempio, i messaggi generati da os_log) e del loro streaming ai client interessati a ricevere questi messaggi. Registrandoci per ricevere il nostro stesso stream diagnostico e inviando poi un messaggio diagnostico con una stringa più corta del previsto, possiamo ottenere un'istantanea di alcuni dati nell'heap di diagnosticd, il che può aiutare a ottenere l'esecuzione di codice nel processo.
Per compilare, esegui make. Vedi la parte superiore del Makefile per le varie opzioni di build.
Esegui l'exploit specificando la dimensione della leak sulla riga di comando:
$ ./xpc-string-leak 0x40
0x2000000000000000 0xe00007ff39bf0992
0x00007fff56858570 0x00007fff7ed23d0e
0x0000000000000000 0x0000000000000000
0x00007fff7ed52be2 0x00007fff7ed29ed6
La dimensione della leak deve essere un multiplo di 8 e almeno 16.
Il codice di xpc-string-leak è rilasciato nel pubblico dominio. Come cortesia, chiedo che, se fai riferimento o usi parte di questo codice, me lo attribuisca.
Ho scoperto questo bug all'inizio del 2018 (gennaio o febbraio), ma ho dimenticato di approfondirlo fino a maggio. Ho segnalato il problema ad Apple il 9 maggio, ed è stato assegnato CVE-2018-4248 e corretto in iOS 11.4.1 e macOS 10.13.6 il 9 luglio.
Brandon Azad