CVE-2026-31431: Rilevamento e Difesa dal Bypass di io_uring dei Sistemi di Rilevamento Esistenti

Ricerca

Per CVE-2026-31431 ("Copy Fail"), abbiamo dimostrato debolezze sistematiche nei prodotti di sicurezza mainstream combinando tre strategie di bypass: percorso I/O asincrono io_uring, splitting dei processi (fork + SCM_RIGHTS) e riutilizzo dei socket. Attraverso test empirici, abbiamo dimostrato che queste tecniche possono eludere praticamente tutti gli strumenti di rilevamento basati sulle syscall.

Risultati Chiave

1. io_uring Bypassa Praticamente Tutti i Rilevamenti Basati su Syscall

io_uring invia richieste tramite buffer ad anello in memoria condivisa, bypassando i punti di ingresso tradizionali delle syscall. Ciò significa che:

auditd / Wazuh / Elastic Security Agent e altri prodotti che dipendono dall'audit delle syscall sono completamente ciechi quando gli attaccanti usano il percorso io_uring — zero eventi, zero alert
I thread di lavoro di io_uring (iou-wrk-XXXXX) eseguono operazioni all'interno del kernel senza attivare audit_syscall_entry()
Le policy Seccomp che bloccano solo socket(AF_ALG) possono essere bypassate tramite IORING_OP_SOCKET — seccomp controlla solo all'ingresso delle syscall, e le operazioni io_uring non passano da quell'ingresso

2. Lo Splitting dei Processi Rompe la Correlazione a Livello di PID

Utilizzando fork + SCM_RIGHTS (passaggio di fd tramite socket Unix domain), la creazione del socket e le operazioni di splice possono essere collocate in processi diversi:

La correlazione same_field(audit.pid) di Wazuh si rompe — PID del socket ≠ PID dello splice, la regola CRITICAL non scatta
Il tracciamento dei fd a livello di processo di Falco libsinsp è completamente compromesso negli scenari SCM_RIGHTS

3. Il Riutilizzo dei Socket Bypassa le Regole Basate su Soglie di Conteggio

Il PoC originale crea un nuovo socket per iterazione (producendo 40+ chiamate socket(AF_ALG)). Il riutilizzo dei socket crea un solo socket in ascolto; il loop chiama accept() che non produce nuovi eventi di socket. Le regole basate su count >= N sono completamente sconfitte.

4. La Combinazione di Varianti Più Difficile da Rilevare

percorso io_uring + splice + /etc/passwd + algoritmo authenc + splitting SCM_RIGHTS + riutilizzo dei socket

Con questa combinazione: gli strumenti basati su syscall sono completamente ciechi, la correlazione a livello di processo è rotta, le soglie di conteggio falliscono. Solo il rilevamento al punto di convergenza con kprobe può intercettare questa combinazione.

5. Il Monitoraggio a Livello LSM Può Rilevare Perfettamente lo Sfruttamento

__sock_create(family=38) è un punto di convergenza non bypassabile per tutti i percorsi (syscall e io_uring) — AF_ALG è l'unica API crittografica userspace nel kernel Linux. Non importa come gli attaccanti varino il loro approccio, devono creare un socket AF_ALG. Monitorare questa funzione a livello LSM fornisce una recall del 100% e non è influenzato da alcuna variante.

Risultati dei Test Specifici per Prodotto

Prodotto	Livello di Rilevamento	Syscall Tradizionale	Percorso io_uring	Split Multi-Processo	Riutilizzo dei Socket	Valutazione
Tetragon (kprobe)	Funzione del kernel	✅	✅	✅	✅	Unica copertura completa della catena
Falco + plugin krsi	fexit/fentry	✅	✅	✅	✅	Richiede krsi per io_uring; solo all'ingresso
Falco (modern_ebpf)	tracepoint syscall	✅	❌	✅	✅	io_uring completamente invisibile
auditd / Wazuh	audit syscall	✅	❌	❌ PID rotto	⚠️	io_uring cieco + correlazione PID rotta
Elastic Security Agent	syscall	✅	❌	⚠️	⚠️	Come Wazuh; dipendente da syscall = cieco

Falco Richiede il Plugin krsi

Il driver nativo modern_ebpf di Falco cattura solo il percorso delle syscall. Il plugin krsi è obbligatorio — utilizza il tracciamento fexit sulle uscite delle funzioni del kernel io_socket() e __sys_socket() per coprire il percorso io_uring per la creazione di socket AF_ALG. Regola di fallback consigliata:

- rule: AF_ALG Socket Created
  condition: >
    (evt.type = socket and evt.args contains AF_ALG) or
    (evt.type = krsi_socket and krsi.domain = 38)
  output: >
    AF_ALG socket created (source=%evt.type domain=%evt.arg.domain
    krsi_domain=%krsi.domain proc=%proc.name pid=%proc.pid)
  priority: WARNING
  tags: [cve-2026-31431, crypto, container_escape]

L'approccio di rilevamento della regola consigliata: copre simultaneamente gli eventi socket (percorso syscall, usando il matching di stringa evt.args contains AF_ALG per bypassare la limitazione del tipo ENUMFLAGS32) e gli eventi krsi_socket (percorso io_uring, usando il confronto intero krsi.domain = 38). Nessuna soglia di conteggio (sconfitta dal riutilizzo dei socket), nessuna dipendenza dalla correlazione PID (sconfitta dallo splitting multi-processo).

Nota: I tre livelli di difesa della regola della community ThreatBear sono tutti bypassabili — disallineamento del tipo ENUMFLAGS32 (evt.arg[0]=38 sempre falso), il riutilizzo dei socket sconfigge la soglia di conteggio (count=1 < 40), lo splitting multi-processo rompe la correlazione PID. Vedi Analisi del Bypass delle Regole.

Wazuh / Elastic Security Agent Non Possono Rilevare lo Sfruttamento di io_uring

Wazuh si affida interamente agli eventi di audit delle syscall di auditd. Le operazioni io_uring non passano dall'ingresso delle syscall, quindi auditd produce zero eventi e tutte le 7 regole di Wazuh falliscono. Lo stesso vale per Elastic Security Agent — i prodotti che dipendono dall'ingresso delle syscall sono strutturalmente ciechi al percorso io_uring. Vedi Analisi delle Limitazioni di Wazuh.

Dimostrazione del Bypass

La directory bypass_demo/ contiene descrizioni concettuali degli approcci di bypass del rilevamento. Il codice PoC effettivo è solo per uso interno e non viene distribuito pubblicamente.

Indice della Documentazione

Teoria

Documento	Contenuto
VULNERABILITY.md	Causa principale — sovrapposizione di tre modifiche al kernel, catena di attacco in 9 passaggi, caratteristiche di scrittura della cache di pagina
EXPLOIT_VARIANTS.md	6 dimensioni delle varianti di exploit — percorso I/O × invio dati × file di destinazione × algoritmo AEAD × splitting dei processi × riutilizzo dei socket
DETECTION_THEORY.md	Teoria del rilevamento — punti di convergenza vs. divergenza, architettura di rilevamento a 4 livelli, correlazione temporale multi-segnale

CVE-2026-31431-detection-defense

Più Popolari