CVE-2022-37706

CVE-2022-37706

Ciao ragazzi, questa volta parlerò di uno 0-day recente che ho trovato in uno dei
principali window manager di Linux chiamato Enlightenment (https://www.enlightenment.org/).
Questo 0-day porta qualsiasi utente ai privilegi di root molto facilmente e all'istante.
L'exploit è stato testato su Ubuntu 22.04, ma dovrebbe funzionare bene su qualsiasi distribuzione.

Prima di tutto, Enlightenment è un Window Manager, un Compositor e un Desktop minimale
per Linux (la piattaforma primaria), BSD e qualsiasi altro sistema UNIX compatibile.

Ho installato questo window manager per sperimentare un po'. Era interessante
per me perché contiene molti strumenti e, a essere onesti, sembra piuttosto curato.

Dopo aver installato il pacchetto usando apt install enlightenment ho esaminato i
file e le directory installati sul mio sistema: molti moduli e molti binari di supporto,
ma la cosa più interessante è:

➜  enlightenment cd /usr/lib/x86_64-linux-gnu/enlightenment/
➜  enlightenment find . -perm -4000                         
./utils/enlightenment_ckpasswd
./utils/enlightenment_system
./utils/enlightenment_sys

Installa alcuni binari SUID; poi ho pensato se potevo usarne uno
per scalare a root. I binari sembravano tutti sicuri e ben codificati.
Il binario di cui parleremo è enlightenment_sys.

Come per qualsiasi altro target, scegliamo una strategia da applicare dopo aver fatto una pre-valutazione;
dai un'occhiata al mio blog qui se non l'hai ancora fatto (https://pwn-maher.blogspot.com/2020/10/vulnerability-assessment.html)

Ho analizzato il codice con un approccio Top-Down.
E poiché questo window manager è open source, il codice sorgente è disponibile
per tutti quei binari e moduli.
Quindi la prima cosa che ho fatto è stata apt source enlightenment per ottenere tutto il codice sorgente,
e, scavando un po', arriviamo al codice del binario target.

Ma per fare il debug del binario l'ho caricato in Ghidra per l'analisi e per avere gli indirizzi
per impostare breakpoint e così via.
Al primo tentativo non sono stati trovati simboli, ma non ce n'era bisogno, dato che
si è rivelato un binario relativamente piccolo.
Sorprendentemente, ho trovato molto più piacevole guardare il pseudo-codice decompilato di
Ghidra che guardare direttamente i sorgenti (evita le macro e anche i controlli
relativi al sistema operativo usato per compilare uno specifico blocco di codice).

Quindi iniziamo l'analisi.

1- Giocare con il binario.
Eseguiamo il file per vedere alcune informazioni sul nostro target:
Screenshot

Eseguire il binario non produce alcun output:
Screenshot

Passare l'argomento --help ha prodotto questo output:
Screenshot
Scusate, lo userò per ottenere root.

Ora facciamo semplicemente uno strace e vediamo se usa qualche syscall sospetta come
execve o openat:
strace ./enlightenment_sys 2>&1 | grep open
Screenshot
Apre solo librerie note in percorsi in cui non abbiamo il permesso di intervenire.

strace ./enlightenment_sys 2>&1 | grep exec
Screenshot

2- Facciamo reverse engineering del binario e poi sfruttiamolo.

Ho creato un nuovo progetto Ghidra e ho caricato questo specifico binario.
Poiché i simboli non sono stati trovati, possiamo individuare la funzione main usando entry.
Il primo argomento della funzione entry è la main stessa.
L'ho rinominata main per riferimenti futuri.
Scorrendo un po' verso il basso noto subito la funzione system() usata.

Come pwner passo giorni su challenge per spawnare questa specifica funzione x)
Ho fatto reverse engineering del binario cercando un bug di memory corruption o qualche problema di heap,
ma in realtà era una strana Command Injection.
Il binario prende tutte le precauzioni di sicurezza prima di eseguire system, ma purtroppo
possiamo sempre iniettare il nostro input lì dentro.
Screenshot

Ok, ora percorriamo il binario dall'inizio fino alla nostra funzione system, cercando
di iniettare il nostro input lì dentro.

Prima il binario controlla semplicemente se il primo argomento è --help o -h e mostra
quel messaggio che abbiamo visto prima.
Screenshot

Poi eleva i suoi privilegi a root.
Screenshot

Successivamente rimuove quasi tutte le variabili d'ambiente (precauzioni di sicurezza) per
non invocare un altro binario non intenzionale.
Screenshot

Quindi se il primo argomento inserito è "mount" entrerà in questo ramo, controllerà alcuni
flag forniti; quei flag verranno impostati sullo stack.

Poi controlla se il parametro successivo dopo mount è UUID=; non vogliamo entrare
qui, quindi abbiamo fornito "/dev/../tmp/;/tmp/exploit".
Screenshot
In questo modo superiamo il controllo alla riga 410, il controllo strncmp.
Perché se non inizia con /dev/ il binario esce.
Poi c'è una chiamata a stat64 su quel file che abbiamo fornito; nota che possiamo
creare una cartella chiamata ";" e questo causerà la command injection.
Screenshot
Screenshot

Ora ci stiamo avvicinando a system().
Ora p (puntatore) viene aggiornato all'ultimo argomento passato al nostro binario SUID,
/tmp///net.

Perché fornire /tmp///net quando possiamo passare /tmp/net?
Supereremo questo controllo:
if (((next_next == (char *)0x0) || (next_next[1] == '\0')) || ((long)next_next - (long)p != 6))
Avevamo bisogno che /tmp/net esistesse e che /tmp/// avesse lunghezza 6.

Ora l'ultima stat64 controllerà l'esistenza di "/dev/net"
__snprintf_chk(cmd,0x1000,1,0x1000,"/dev%s",next_next);
E lo troverà, quindi superiamo anche questo ultimo controllo.

Ora controllerà la disponibilità di alcuni file, ma a questo punto
non è importante, perché siamo a posto e vicinissimi a innescare l'esecuzione arbitraria
di comandi.

Ora eina_strbuf_new() inizializza semplicemente il comando che verrà passato a
system; il problema qui è che l'abbiamo inserito come:

/bin/mount -o noexec,nosuid,utf8,nodev,iocharset=utf8,utf8=0,utf8=1,uid=$(id -u), "/dev/../tmp/;/tmp/exploit" /tmp///net

Ma il binario chiama eina_strbuf_append_printf() diverse volte e il comando diventa

/bin/mount -o noexec,nosuid,utf8,nodev,iocharset=utf8,utf8=0,utf8=1,uid=$(id -u), /dev/../tmp/;/tmp/exploit /tmp///net
Nota che i doppi apici vengono rimossi e saremo in grado di chiamare /tmp/exploit
come root.
Screenshot

Il binario ha fatto del suo meglio per mitigare qualsiasi comportamento non intenzionale,
ma come al solito qualsiasi cosa può essere pwnata.
Non mi aspettavo di sfruttarlo con un bug logico del genere.
Voglio che la prossima CVE sia una corruzione della memoria che porti a una LPE come root.