Nessuno dei due bug da solo è completamente affidabile — il percorso ESP richiede la capacità di creare un user namespace (che l'AppArmor di Ubuntu blocca), e il percorso RxRPC richiede che rxrpc.ko sia caricato (cosa che la maggior parte delle distribuzioni non fa di default). Insieme coprono i rispettivi punti ciechi, rendendo la catena funzionante su praticamente ogni distribuzione principale.

È disponibile un proof-of-concept pubblico. Considera che sia già in uso attivo.

Cosa fa questo script

Controlla il tuo sistema per le condizioni che rendono possibile lo sfruttamento e ti dice specificamente perché sei esposto — non solo un sì o un no.

Non correggerà nulla. Non sfrutterà nulla. Ti dice solo la verità sul tuo sistema.

Requisiti

• Python 3.6+
• Nessuna dipendenza esterna — solo stdlib
• Nessun requisito di root (intenzionalmente — controlliamo ciò che un attaccante non privilegiato può vedere)

Utilizzo

Tutto qui. Output con codifica a colori, motivi specifici per ogni risultato e un riepilogo delle misure correttive alla fine.

Screenshot

[]

Come risolvere

La vera soluzione è applicare la patch al kernel. Controlla gli advisory di sicurezza della tua distribuzione:

Nell'attesa (o se le patch non sono ancora disponibili per la tua distribuzione), metti in blacklist i moduli vulnerabili:

⚠️ Prima di farlo:

• Mettere in blacklist esp4/esp6 interromperà i tunnel IPsec (strongSwan, Libreswan; WireGuard non è interessato). Non applicare questo su gateway VPN.
• Mettere in blacklist rxrpc interromperà i client del filesystem distribuito AFS. Quasi nessuno lo usa — ma controlla prima.

Importante: se il tuo sistema potrebbe essere stato preso di mira prima dell'applicazione della mitigazione, l'exploit può modificare i binari nella page cache senza toccare il disco. Gli strumenti di integrità dei file (Tripwire, AIDE) che controllano i checksum su disco non vedranno nulla di anomalo. Il riavvio pulisce la page cache e ripristina lo stato su disco.

Come funziona (la versione breve)

Entrambi i bug risiedono nei percorsi rapidi di decrittazione in-place del kernel. Quando un buffer di socket trasporta frammenti paginati che non sono di proprietà privata del kernel — ad esempio, pagine di pipe allegate tramite splice() o sendfile() — i percorsi di ricezione ESP e RxRPC decrittano direttamente su quelle pagine supportate esternamente invece di copiarle prima.

Un attaccante può indirizzare una pagina dalla cache di /usr/bin/su (o qualsiasi altro file leggibile) in uno di questi percorsi di decrittazione, usando la propria chiave così che l'"output decrittato" sia qualsiasi byte scelga. Il kernel scrive quei byte direttamente nella copia in memoria cache di su. Il file su disco è intatto. Il kernel non marca mai la pagina come sporca.

Da quel momento, ogni processo che esegue su esegue la versione dell'attaccante — fino a drop_caches o a un riavvio.

La variante ESP (cac2661c53f3) e la variante RxRPC (2dc334f1a63a) condividono lo stesso sink ma hanno prerequisiti diversi che si annullano a vicenda, rendendo la catena affidabile su tutte le configurazioni principali.

Per l'analisi tecnica completa, vedi V4bel/dirtyfrag.

Cronologia della divulgazione

Crediti: Hyunwoo Kim (@v4bel) per la ricerca originale, la divulgazione e il PoC.

Disclaimer

Solo rilevamento. Puntalo su sistemi che sei autorizzato a valutare.