CVE-2022-37706-LPE-exploit

CVE-2022-37706

Hola chicos, esta vez voy a hablar de un 0-day reciente que encontré en uno de los
principales gestores de ventanas de Linux llamado Enlightenment (https://www.enlightenment.org/).
Este 0-day lleva a cualquier usuario a privilegios de root muy fácil e instantáneamente.
El exploit está probado en Ubuntu 22.04, pero debería funcionar sin problemas en cualquier distro.

En primer lugar, Enlightenment es un gestor de ventanas, compositor y escritorio mínimo
para Linux (la plataforma principal), BSD y cualquier otro sistema UNIX compatible.

Instalé este gestor de ventanas para experimentar un poco con él. Me resultó interesante
porque contiene muchas herramientas y, siendo honesto, se ve bastante prolijo.

Después de instalar el paquete con apt install enlightenment, examiné los
archivos y directorios instalados en mi sistema: muchos módulos y muchos binarios
auxiliares, pero lo más interesante es:

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

Instala algunos binarios SUID; entonces pensé si podría usar uno de ellos
para escalar a root. Los binarios tenían una apariencia segura y estaban bien codificados.
El binario del que hablaremos es enlightenment_sys.

Como con cualquier otro objetivo, elegimos una estrategia a aplicar después de hacer una evaluación previa.
Si aún no lo has visto, mira mi blog aquí (https://pwn-maher.blogspot.com/2020/10/vulnerability-assessment.html)

He auditado el código con un enfoque de arriba hacia abajo (Top-Down).
Y como este gestor de ventanas es de código abierto, el código fuente está disponible
para todos esos binarios y módulos.
Así que lo primero que hice fue apt source enlightenment para obtener todo el código fuente,
y con un poco de búsqueda podemos llegar al código del binario objetivo.

Pero para depurar el binario lo cargué en Ghidra para analizarlo y tener direcciones
donde poner puntos de interrupción, etc.
No se encontraron símbolos al primer intento, pero no los necesitamos porque resultó
ser un binario relativamente pequeño.
Sorprendentemente, me resultó mucho más agradable mirar el pseudocódigo descompilado de
Ghidra que mirar directamente el código fuente (evita macros y también esas comprobaciones
sobre el sistema operativo usado para compilar un bloque de código específico).

Entonces, comencemos el análisis.

1- Jugar con el binario.
Ejecutemos el archivo para ver información sobre nuestro objetivo:

Ejecutar el binario no produce ninguna salida:

Pasar el argumento --help muestra esta salida:

Lo siento, lo usaré para obtener root.

Ahora usemos strace para ver si realiza alguna syscall sospechosa como
execve u openat:
strace ./enlightenment_sys 2>&1 | grep open

Simplemente abre librerías conocidas en lugares donde no tenemos permiso para manipular.

strace ./enlightenment_sys 2>&1 | grep exec

2- Vamos a aplicar ingeniería inversa al binario y luego explotarlo.

Creé un nuevo proyecto de Ghidra y cargué este binario en concreto.
Como no se encontraron símbolos, podemos localizar la función main usando entry.
El primer argumento de la función entry es la propia main.
La renombré a main para futuras referencias.
Bajando un poco ya puedo ver que se usa la función system().

Como pwner, paso días en retos para invocar esta función x)
Hice ingeniería inversa al binario buscando un bug de corrupción de memoria o problemas de heap,
pero en realidad era una extraña inyección de comandos.
El binario toma todas las precauciones de seguridad antes de ejecutar system, pero por desgracia
siempre podemos inyectar nuestra entrada ahí.

Ok, ahora recorramos el binario desde el principio hasta nuestra función system, intentando
inyectar nuestra entrada ahí.

Primero, el binario solo comprueba si el primer argumento es --help o -h y muestra ese
mensaje que vimos antes.

Segundo, eleva sus privilegios a root.

Luego, elimina casi todas las variables de entorno (precauciones de seguridad) para no
invocar otro binario no deseado.

Entonces, si el primer argumento que introducimos es "mount", entrará en esta rama, comprobará algunas
banderas dadas, y esas banderas se colocarán en la pila.

A continuación comprueba si el siguiente parámetro después de mount es UUID=; no queremos entrar
aquí, así que proporcionamos "/dev/../tmp/;/tmp/exploit".

De esta manera pasamos la comprobación de la línea 410, la comprobación strncmp.
Porque si no comienza con /dev/, el binario saldrá.
Después hay una llamada a stat64 sobre ese archivo que proporcionamos; nota que podemos
crear una carpeta llamada ";" y eso causará la inyección de comandos.
Hasta ahora, el exploit ya ha creado este archivo /dev/../tmp/;/tmp/exploit,
pero este no es el exploit que se invocará.

Ya nos acercamos a system().
Ahora p (puntero) se actualiza al último argumento que se le pasa a nuestro binario SUID,
/tmp///net.

¿Por qué proporcionar /tmp///net si podemos pasar /tmp/net?
Vamos a saltarnos esta comprobación:
if (((next_next == (char *)0x0) || (next_next[1] == '\0')) || ((long)next_next - (long)p != 6))
Necesitábamos que /tmp/net existiera y que /tmp/// tuviera una longitud de 6.

Ahora el último stat64 comprobará la existencia de "/dev/net".
__snprintf_chk(cmd,0x1000,1,0x1000,"/dev%s",next_next);
Y lo encontrará, así que pasamos esa última comprobación.

Ahora comprobará la disponibilidad de algunos archivos, pero eso no es importante
en este punto, porque ya está todo listo y estamos cerca de desencadenar la ejecución
arbitraria de comandos.

Ahora eina_strbuf_new() simplemente inicializa el comando que se pasará a
system; el problema aquí es que lo introdujimos como:

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

Pero el binario llama a eina_strbuf_append_printf() varias veces y el comando se convierte en
/bin/mount -o noexec,nosuid,utf8,nodev,iocharset=utf8,utf8=0,utf8=1,uid=$(id -u), /dev/../tmp/;/tmp/exploit /tmp///net
Observa que se eliminan las comillas dobles, y podremos invocar /tmp/exploit
como root.

El binario hizo todo lo posible por mitigar cualquier comportamiento no deseado, pero como siempre,
todo se puede vulnerar. No esperaba explotar esto mediante un bug lógico
como este.
Quiero que el próximo CVE sea una corrupción de memoria que permita una escalada local de privilegios (LPE) a root.

Divulgación en Twitter: https://twitter.com/maherazz2/status/1569665311707734023