Modifica ./configure, sovrascrivendolo direttamente con il seguente contenuto

Esecuzione

Analisi della vulnerabilità

Prima analizziamo la patch in base64.c: Qui result è il buffer che contiene il risultato della decodifica base64, ottenuto tramite la funzione store_get. Si può notare che il calcolo di size prima della patch è errato: quando size rientra nell'intervallo 4n~4n+3, la lunghezza calcolata è identica, ma b64decode, decodificando un input la cui lunghezza non è multipla di 4, produce uno o due byte in più.

Ad esempio, se inviamo direttamente

size=0x40
La distribuzione della memoria è:

Proviamo anche

size=0x40

Si ha un overflow di due byte.

Meccanismo di gestione della memoria di Exim

Per migliorare le prestazioni, exim ha implementato un proprio meccanismo di gestione della memoria sopra quello dell'heap originale; funge da buffer intermedio tra il codice e glibc, con l'obiettivo di ridurre il numero di chiamate a malloc e free. Per exim, un singolo chunk dell'heap è chiamato storeblock; ogni volta che viene usato, da esso viene ricavato un buffer di dimensione adeguata. Quando uno storeblock è esaurito, viene allocato un nuovo storeblock con malloc. Per ogni storeblock, la sua struttura è una semplice lista concatenata singola:

Le principali API usate dal programma per l'heap si trovano in store.c:

Tra queste, store_get è usata per ottenere il buffer; il codice chiave è il seguente:

Si può notare che la lunghezza minima di ogni store_block richiesto è STORE_BLOCK_SIZE, cioè 8192.

Quindi uno store_block di dimensione 8192, aggiungendo l'header della struttura e l'header del chunk dell'heap, ha una dimensione totale di 0x2020.

Ogni volta che exim esegue un comando inviato dal client, se il comando ha successo, viene chiamata store_reset per liberare le cache non necessarie e gli store_block in eccesso.
Qui "eseguito con successo" significa che il formato del comando è corretto, l'indirizzo email non contiene caratteri non validi, ecc.; altrimenti store_reset non viene chiamata.

Strategia di exploit

Questa vulnerabilità è un classico off-by-one (anche se in realtà si può eccedere di due byte), ma poiché i byte di overflow sono pochi, non è possibile sovrascrivere direttamente le strutture sensibili nel chunk. Quindi è necessario sfruttare alcune caratteristiche di ptmalloc per amplificare l'impatto di questa vulnerabilità, trasformandola in un overflow su un'area più vasta, o meglio in un overlap.
Per le vulnerabilità off-by-one, esiste un classico metodo di sfruttamento: chunk enlarge -> chunk overlap. Ingrandendo la size del chunk e falsificando un header del chunk per bypassare i sanity check di glibc, si ottiene l'overlap dei chunk, consentendo una copertura su un'area più ampia. Qui il processo principale è: chunk enlarge -> chunk overlap -> corruzione del puntatore next nello storeblock, quindi innescare store_reset per causare la free di un chunk arbitrario; una volta riallocato questo chunk, si può modificarne il contenuto (type confusion). meh nel suo articolo consiglia di modificare il chunk in cui si trova la stringa ACL, perché nella gestione delle stringhe ACL esiste una funzionalità di esecuzione comandi. Le stringhe ACL sono moltissime, ma la maggior parte sono NULL (probabilmente a causa del file di configurazione). Qui ho scelto la stringa acl_smtp_mail; la sintassi per eseguire comandi è:

Il layout dell'heap è più o meno il seguente:

Il primo chunk è quello ottenuto dalla decodifica base64, usato per l'off-by-one; quindi deve trovarsi alla fine di uno storeblock. Per comodità, qui si alloca direttamente un chunk più grande di 0x2020 per contenere il risultato della decodifica base64;
Il secondo chunk è sender_helo_name, usato per sovrascrivere il chunk successivo. sender_helo_name non è memorizzato in uno storeblock, ma viene allocato direttamente con malloc:

Quindi la sua dimensione è arbitraria;
Il terzo chunk è ottenuto dalla decodifica base64, usato principalmente per falsificare l'header e venire sovrascritto; quindi deve trovarsi all'inizio di uno storeblock. Per comodità, si alloca anch'esso direttamente con dimensione 0x2020.

Exploit

La mia exploit è stata ottenuta seguendo passo dopo passo le analisi pubblicate online da altri; l'idea generale è identica, ma il layout dell'heap è leggermente diverso da quello degli altri, quindi alcuni piccoli parametri sono differenti.

Prima si genera una unsorted bin di dimensione 0x6060; basta il seguente comando per realizzarla:

Quando exim riceve "EHLO "+'a'\*0x1000, nella funzione match_check_list di match.c vengono generate le seguenti tre stringhe:

Poiché name ha lunghezza 0x1000, ogni stringa occuperà da sola uno storeblock; queste tre stringhe saranno quindi rispettivamente in tre storeblock consecutivi. Quando exim completa con successo il comando ehlo, in smtp_in.c, nella funzione smtp_setup_msg, le tre stringhe precedenti vengono liberate, ottenendo un chunk di dimensione 0x6060:

Il layout dell'heap in questo momento è il seguente:

Per posizionare sender_helo_name al centro dell'heap, dobbiamo liberare il vecchio sender_helo_name, occupare il chunk in cima; dopo che il secondo sender_helo_name viene allocato, si libera il chunk in cima.
Qui uso il comando unrecognize per l'occupazione. Poiché ricevere un comando unrecognize equivale a un comando fallito, al successivo comando eseguito con successo verrà liberato automaticamente.
Da notare che il principio dell'occupazione con unrecognize command è che, dopo aver inviato il comando a exim, exim chiama synprot_error per segnalare l'errore, simile a:

Ma se il comando è composto interamente da caratteri visibili, exim non alloca un nuovo chunk con malloc:

Se il comando contiene caratteri non visibili, exim alloca un nuovo buffer e converte i caratteri non visibili in stringhe ottali, ad esempio '\xee' -> "\356"; questa è l'origine di length + (nonprintcount * 3 + 1).

Quindi prima si inserisce sender_ehlo_name in un piccolo chunk, poi si prova a inviare 0x800 byte '\xee'; questo richiederà 0x800 + 1 + 0x800 * 3=0x2001. Nello storeblock corrente non c'è uno spazio così grande, quindi verrà allocato un nuovo store_block.

Poi si alloca un sender_elho_name di dimensione 0x2010:

In questo modo il vecchio sender_elho_name di 0x20 viene liberato per primo:

Poi viene allocato un nuovo sender_helo_name; quando tutto è completato, store_reset viene chiamata per eliminare i chunk non necessari. Così il messaggio di errore di dimensione 0x2020 viene liberato e, insieme al sender_helo_name già liberato sopra, subisce una malloc_consolidate formando un nuovo chunk di dimensione 0x2050:

A questo punto il layout dell'heap è sostanzialmente completo; successivamente si procede direttamente con l'occupazione e l'innesco della vulnerabilità.

Si occupa il chunk in cima, eccedendo di un byte la size da 0x2021 a 0x20f1. Poi si occupa il chunk in fondo, falsificando una size di 0x1f61 per farlo puntare al chunk successivo.

Qui si alloca un altro chunk, perché altrimenti lo storeblock sovrascritto sarebbe l'ultimo storeblock e next sarebbe null.

A questo punto si può liberare sender_helo_name per creare un chunk overlap. C'è però un punto da notare: siccome abbiamo ancora bisogno del chunk in fondo per fornire il puntatore next (lo sovrascriviamo per ottenere una free a un indirizzo arbitrario), non vogliamo che questo chunk venga liberato; quindi si può costruire un name non valido per liberare solo sender_helo_name:

Se check_helo fallisce, il programma esce da questo ciclo senza chiamare store_reset; allora diamo un'occhiata alla logica di check_helo:

Si può vedere che check_helo esegue alcuni controlli sui caratteri inviati: devono essere lettere o certi segni di punteggiatura, oppure devono essere in helo_allow_chars. Tuttavia di solito helo_alow_chars è vuoto; dovrebbe essere configurato nel file di configurazione. Quindi possiamo costruire un sender_helo_name con spazi:

In questo modo si ottiene l'overlap dei chunk. Poi si occupa questo chunk per sovrascrivere il puntatore next facendolo puntare al chunk contenente la stringa ACL. C'è un problema: le altre exploit usano una sovrascrittura parziale per bypassare ASLR, ma nel mio ambiente non funziona, perché il chunk ACL e il chunk puntato da next sono molto distanti.

Per questo la mia exploit usa un indirizzo assoluto.

In questo modo il chunk che contiene acl_string viene aggiunto alla catena di questo store_block; quando cambiamo sender_helo_name, tutti questi chunk verranno liberati in store_reset. Quindi questa volta bisogna inviare un nome valido:

Questa volta, allocando di nuovo un chunk, si potrà ottenere il chunk in cui si trova la stringa ACL:

Qui sovrascrivo l'indirizzo puntato da acl_smtp_mail. In pratica tutte le stringhe ACL sono in questo chunk, perché queste stringhe vengono lette una per una da configure e inserite nel buffer ottenuto con store_get; quindi sono memorizzate in modo contiguo in questo storeblock. Infine si chiama l'API relativa all'ACL:

Poi, in smtp_setup_msg -> acl_check -> acl_check_internal -> expand_string -> expand_cstring -> expand_string_internal -> child_open -> child_open_uid, viene chiamata execve per eseguire il comando presente in run. Di seguito le informazioni di debug lato server: si può vedere che il comando è stato effettivamente eseguito.

Reference

https://medium.com/@straightblast426/my-poc-walk-through-for-cve-2018-6789-2e402e4ff588 https://github.com/skysider/VulnPOC/tree/master/CVE-2018-6789