veritas501/pipe-primitiveUna primitiva de explotación en el kernel de Linux inspirada en DirtyPipe
Una primitiva de explotación en el kernel de Linux inspirada en DirtyPipe (CVE-2022-0847).
Hace unos días, como muchos predecesores en seguridad, estudié y reproduje la vulnerabilidad DirtyPipe (CVE-2022-0847), y sentí profundamente lo útil que es este agujero. Este agujero comienza con un problema de memoria no inicializada y termina con la modificación de archivos arbitrarios, y en el proceso no implica fugas de KASLR ni operaciones como ROP, JOP. Por lo tanto, no es necesario eludir protecciones como SMEP, SMAP.
Después de reproducirlo, empecé a pensar: ¿por qué es tan útil el agujero DirtyPipe? ¿Acaso con el parche de DirtyPipe, desaparecerá como un destello, sin ningún valor de aprendizaje para la explotación de vulnerabilidades futura?
De repente, me di cuenta de que la estructura donde reside DirtyPipe, struct pipe_buffer, me resultaba muy familiar. ¡Ah! ¿No era esa estructura asignada con el flag GFP_KERNEL_ACCOUNT, ubicada en slab-1k, y que contiene un campo ops que solía usar para hacer fugas de KASLR y secuestro de RIP?
Enseguida me sentí como un tonto: ¿por qué modificaba el ops de pipe_buffer para hacer ROP? ¡Si modificando directamente los flags de pipe_buffer y combinándolo con splice se podía lograr la escritura de archivos arbitrarios! Así no tendría que filtrar KASLR, tampoco adaptar el exploit a diferentes versiones del kernel, ni preocuparme por los gadgets, ni necesidad de eludir SMEP, SMAP, KPTI, etc.
Inmediatamente saqué los exploits que había reproducido antes para aprender CVE-2021-22555 y otros que involucran la estructura pipe_buffer, los modifiqué ligeramente y pude explotarlos con éxito en diferentes versiones de kernel sin parches. Aquí hay algunos ejemplos:
Como hasta ahora no había visto a nadie usarlo como primitiva en exploits del kernel de Linux, me tomé la libertad de llamarlo "Pipe Primitive" XD.
Resumiendo, lo que se necesita es obtener la capacidad de modificar la estructura Pipe; por ejemplo, puede ser un UAF en slab-1k, o una escritura fuera de límites con desplazamiento en slab-1k (es decir, no un desbordamiento directo en orden).
De esta manera, en kernel >= 5.8, solo necesitamos modificar el flag |= PIPE_BUF_FLAG_CAN_MERGE de la página splice en pipe_buffer (si se puede, también cambiar offset y len a 0, para poder escribir desde el principio del archivo); en kernel < 5.8, primero hay que filtrar anon_pipe_ops en pipe_buffer, y luego cambiar el ops de la página splice a anon_pipe_ops (porque en versiones <5.8, si se puede merge depende de ops) (si se puede, también cambiar offset y len a 0).
En cuanto a si preguntas cómo hacer el escape de contenedores con esto, lo que quiero hacer debería ser similar a CVE-2019-5736 XD.
