veritas501/pipe-primitiveUna primitiva di exploit nel kernel Linux ispirata a DirtyPipe
An exploit primitive in linux kernel inspired by DirtyPipe (CVE-2022-0847).
Alcuni giorni fa, come molti esperti di sicurezza prima di me, ho studiato e riprodotto la vulnerabilità DirtyPipe (CVE-2022-0847), rendendomi profondamente conto di quanto sia utile. La falla nasce da un problema di memoria non inizializzata e porta alla modifica di file arbitrari, senza coinvolgere leak di KASLR o operazioni come ROP e JOP. Non è quindi necessario aggirare protezioni come SMEP o SMAP.
Dopo la riproduzione, ho iniziato a chiedermi: perché DirtyPipe è così utile? Forse, con la sua correzione, svanirà come un fiore effimero, senza più alcun valore di apprendimento per lo sfruttamento delle vulnerabilità future?
All'improvviso ho capito che la struttura in cui vive DirtyPipe — struct pipe_buffer — sembrava molto familiare. Ah! Non è forse quella struttura allocata con il flag GFP_KERNEL_ACCOUNT, situata in slab-1k, e con un campo ops che uso spesso per il leak di KASLR e il dirottamento di RIP?
Subito dopo mi sono sentito uno sciocco: perché avevo modificato ops di pipe_buffer per fare ROP? Modificando direttamente flags di pipe_buffer e usando splice si poteva già scrivere su file arbitrari! Così non c'è bisogno di fare leak di KASLR, né di adattare l'exploit a diverse versioni del kernel, né di preoccuparsi di gadget, né di aggirare protezioni come SMEP, SMAP o KPTI.
Ho subito tirato fuori gli exploit che avevo usato per studiare CVE-2021-22555 e altri che coinvolgono la struttura pipe_buffer; con piccole modifiche sono riuscito a utilizzarli con successo su diverse versioni del kernel senza patch. Ecco alcuni esempi:
Dato che fino ad ora non ho visto nessuno usarla come primitiva negli exploit per il kernel Linux, mi sono preso la libertà di chiamarla “Pipe Primitive” XD.
In sintesi, serve ottenere la capacità di modificare la struttura Pipe, ad esempio tramite una UAF in slab-1k, oppure una scrittura fuori dai limiti in slab-1k con offset (cioè non un overflow diretto in sequenza).
Così, nel kernel >= 5.8, dobbiamo solo modificare flag |= PIPE_BUF_FLAG_CAN_MERGE nella pagina splice di pipe_buffer (se si è in grado, si possono anche impostare offset e len a 0, in modo da poter scrivere dall'inizio del file); nel kernel < 5.8, bisogna prima fare leak di anon_pipe_ops in pipe_buffer, poi cambiare ops della pagina splice in anon_pipe_ops (perché nelle versioni < 5.8 la possibilità di fare merge dipende da ops) (se si è in grado, si possono comunque impostare offset e len a 0).
E se mi chiedi come si farebbe la fuga dal container? Penso che sarebbe più o meno come CVE-2019-5736, XD.
