Linux, un punto esclamativo di troppo per sbloccare i permessi di root

Linux, un punto esclamativo di troppo per sbloccare i permessi di root

Un controllo invertito in nf_tables, corretto a monte da febbraio con una riga, permette a un utente locale senza privilegi di diventare root e uscire dal container. Exodus e FuzzingLabs hanno pubblicato due exploit su Debian, Ubuntu e RHEL

di pubblicata il , alle 10:31 nel canale Sicurezza
Linux
 

Un punto esclamativo di troppo nel codice del kernel Linux è bastato a trasformare un utente senza privilegi in root. È la sintesi della falla CVE-2026-23111, una use-after-free nel sottosistema nf_tables di netfilter per cui nelle scorse ore Exodus Intelligence ha pubblicato un exploit completo e funzionante.

La vulnerabilità era già stata corretta a monte il 5 febbraio 2026, con una modifica di una sola riga, e non è nemmeno il primo codice di attacco reso pubblico: FuzzingLabs ne aveva diffuso una riproduzione indipendente già ad aprile. Ubuntu classifica la falla con un punteggio CVSS 7.8, alto.

La falla non apre alcun varco da remoto, in quanto si tratta di una strada che un attaccante potrebbe percorrere solo dopo aver già messo piede sul sistema, per promuovere a root una shell a con permessi bassi, un container compromesso o un account di servizio, ed evadere così dall'isolamento verso la macchina ospite.

Un controllo invertito nella fase di abort

Il problema vive in nft_map_catchall_activate(), la funzione che durante l'annullamento di una transazione nf_tables dovrebbe riattivare gli elementi catchall di una mappa. Un controllo di attività invertito, un'unica negazione di troppo, fa sì che la funzione salti gli elementi inattivi e ne elabori di attivi, l'opposto di quanto la logica richiede. La correzione a monte si è limitata a togliere quel carattere.

La conseguenza è che a ogni ciclo di annullamento fallito il contatore dei riferimenti di una catena viene decrementato in modo permanente. Portato a zero, lascia liberare la catena mentre altri oggetti la referenziano ancora, ed è qui che si apre la use-after-free sfruttabile per la scalata dei privilegi.

Il presupposto è una configurazione molto diffusa: nf_tables insieme agli user namespace senza privilegi, la funzione che permette a un account ordinario di agire da amministratore dentro una sandbox isolata e raggiungere codice del kernel altrimenti fuori portata. Entrambi gli ingredienti sono attivi di default su gran parte dei desktop e su molte installazioni server.

Due strade verso lo stesso root

Le due dimostrazioni hanno imboccato percorsi tecnici diversi. Exodus attribuisce la scoperta al ricercatore Oliver Sieber, che individuò il bug all'inizio del 2025 e lo ha poi incatenato in una scalata completa a root, con tanto di evasione dal namespace del container. La dimostrazione ha funzionato su Debian Bookworm e Trixie e su Ubuntu 22.04 e 24.04 LTS, con una stabilità superiore al 99% su sistema a riposo, che scende all'80% sotto forte pressione sulla memoria del kernel.

FuzzingLabs era arrivata prima e da un'altra direzione: in preparazione del Pwn2Own Berlin 2026 ha riprodotto il bug su Red Hat Enterprise Linux 10, costruendo un proprio exploit fino all'esecuzione di una catena ROP per ottenere i privilegi di root. La cronologia è abbastanza serrata: correzione a monte il 5 febbraio, pubblicazione di FuzzingLabs il 16 aprile, analisi dettagliata di Exodus l'8 giugno.

CVE-2026-23111 si inserisce in una sequenza fitta di scalate locali su Linux. Nelle ultime settimane sono emerse Copy Fail, la catena Dirty Frag con la sua variante Fragnesia, DirtyDecrypt e una falla in ptrace vecchia di nove anni, capace di leggere /etc/shadow ed eseguire comandi come root. Secondo una recente analisi di Synacktiv, il ritmo è alimentato dalla ricerca assistita dall'IA e dal confronto fra le versioni delle patch, che mette in circolazione exploit funzionanti prima che le correzioni si diffondano.

Il rimedio è abbastanza scontato: aggiornare il kernel e riavviare. Ubuntu ha distribuito le correzioni per 22.04, 24.04 e 25.10, Debian per Bookworm e Trixie con un backport su 6.1 per Bullseye LTS, mentre Red Hat, SUSE e Amazon Linux seguono la falla con versioni corrette che variano da distribuzione a distribuzione. Non risultano al momento sfruttamenti attivi, ma il codice di attacco circola dall'aprile scorso: dove la patch non può essere applicata subito, conviene almeno restringere chi è autorizzato a creare user namespace senza privilegi.

21 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
coschizza09 Giugno 2026, 10:38 #1
ma linux non era sicuro e innattaccabile ? no era come ho sempore detto io un software quindi ha gli isterssi problemi di qualsiai altro software al mondo essendo fatto da persone in carne e do ossa quindi non infallibili per definizione
UtenteHD09 Giugno 2026, 10:49 #2
Originariamente inviato da: coschizza
ma linux non era sicuro e innattaccabile ? no era come ho sempore detto io un software quindi ha gli isterssi problemi di qualsiai altro software al mondo essendo fatto da persone in carne e do ossa quindi non infallibili per definizione


Se leggi tutte le documentazioni nessuno documenta che Linux sia inattaccabile (in molte situazioni molto sicuro, ma la cosa più importante è sempre il cervello di chi lo usa, il 90% degli attacchi sfrutta l'Utente), ha alcuni sistemi migliori di altri, ma nulla è inattaccabile, considerato che molti server se non quasi tutti hanno Linux è di interesse dei farabutti attaccarlo.
Idem per Mac ad esempio, quando non era di largo uso sembrava inattaccabile perchè non preso di mira, ora invece nei siti di cybersecurity tipo i rec cyber si legge di tutto e per ogni SO ed ogni dispsitivo, soprattutto per i dispsitivi IT spesso lasciati senza protezioni o misere senza aggiornamenti, vedasi attacco DDOS eseguito sfruttando migliaia/miliardi di spazzolini da denti (ma c'e' bisogno di collegare ad internet lo spazzolino? inutile ed assurdo aumentare inutilmente le porte di attacco, ma almeno attivate fireewall nel router e cambiate la password di default)
La differenza semmai è che per Linux quasi ogni giorno escono patch di aggiornamento, io li aggiorno ogni 2gg in auto rilevamento, e Windows non lo uso più da 4 anni, manco per giocare con Steam.
matrix8309 Giugno 2026, 10:51 #3
Originariamente inviato da: coschizza
ma linux non era sicuro e innattaccabile ? no era come ho sempore detto io un software quindi ha gli isterssi problemi di qualsiai altro software al mondo essendo fatto da persone in carne e do ossa quindi non infallibili per definizione

Non l'ha mai detto nessuno. Sono decessi ceh si bucano *unix. tutte le botnet sono quasi 100% *nix. Solo voi webeti lo usavate per deridere chi usava linux.
In ogni caso *nix rimane mille volte più sicuro di sistemi Windows.
Sono tutti bug per cui devi avere già accesso al sistema.
E' ovvio che visto che la quasi totalità dei server sono linux è più facile avere una situazione multiutente con accesso a terzi. Su windows già è tanto se si avvia l'unico utente principale
moklev09 Giugno 2026, 10:52 #4
Originariamente inviato da: coschizza
ma linux non era sicuro e innattaccabile ? no era come ho sempore detto io un software quindi ha gli isterssi problemi di qualsiai altro software al mondo essendo fatto da persone in carne e do ossa quindi non infallibili per definizione


Vulnerabilità corretta il 5 febbraio 2026, riprodotto in maniera indipendende ad aprile 2026, reso pubblico l'8 giugno. Cosa non ti torna? CVE-2026-23111 praticamente non è mai atterrato nella distribuzione di Debian Trixie. Se era un baco di MS o Apple ci stava degli anni in stato di pending... il sistema di revisione open source dimostra di funzionare con una rapidità accettabile (<quasi> sempre, la perfezione non esiste).
Ibanez8909 Giugno 2026, 10:55 #5
Originariamente inviato da: coschizza
ma linux non era sicuro e innattaccabile ? no era come ho sempore detto io un software quindi ha gli isterssi problemi di qualsiai altro software al mondo essendo fatto da persone in carne e do ossa quindi non infallibili per definizione


Spero sia solo un bait uscito male, altrimenti non me lo spiego da un Senior Member di questo Forum.
Saturn09 Giugno 2026, 10:56 #6
Don't feed the troll !
marcram09 Giugno 2026, 11:12 #7
'Mmazza quanti utenti Linux si manifestano ultimamente nella sezione news...
La missione di Coschizza ormai è stanarci tutti!
metrino09 Giugno 2026, 11:55 #8
Originariamente inviato da: coschizza
ma linux non era sicuro e innattaccabile ? no era come ho sempore detto io un software quindi ha gli isterssi problemi di qualsiai altro software al mondo essendo fatto da persone in carne e do ossa quindi non infallibili per definizione

Non so perché ma mi ricorda quando Trump nel 2017 disse che la gelata di New York dimostrava che il riscaldamento del clima era una fake news. Confondeva ignorantemente un evento locale con il clima, che misura eventi globali a distanza anche di anni.
Si potrebbe dire lo stesso, si confonde una singola falla con la tendenza generale.

Si stima che in Linux siano latenti 15K-18K di bug di cui una frazione (stima del 3,5%) sono bug di sicurezza. Una volta che una falla è stata scoperta e certificata, viene chiusa in 24-48 ore se critica, un paio di settimane in caso contrario. Il codice ovviamente deve poi essere distribuito ma questo dipende dalle politiche delle varie distro, facciamo che alla peggio ci vogliono tra 15 e 30 giorni totali per una falla di sicurezza non critica. Questi segnalazioni di falle sono aumentate a dismisura da poco grazie (A causa) dell'AI che ne sta individuando tante, e tra queste molte "cosmetiche" come le definisco io, ossia inutilizzabili in realtà da un attaccante.

La stima per windows è di 50K-60K (stima 5% bug di sicurezza). Per le falle zero-day ci mette normalmente 7-15 giorni a fixarle (48 ore in casi estremi) ma normalmente ci mette dai 60 ai 90 giorni distribuendo la patch con i patch day. Sono noti casi in cui MS ha ignorato una falla zero-day per mesi.

Tutto ciò per dire cosa?
1. un sistema inattaccabile non esiste (e grazie al ...)
2. esistono però sistemi molto meno attaccabili di altri (e qui casca l'asino)

Originariamente inviato da: marcram
'Mmazza quanti utenti Linux si manifestano ultimamente nella sezione news...
La missione di Coschizza ormai è stanarci tutti!

In effetti...
aqua8409 Giugno 2026, 11:57 #9
Originariamente inviato da: coschizza
ma linux non era sicuro e innattaccabile ? no era come ho sempore detto io un software quindi ha gli isterssi problemi di qualsiai altro software al mondo essendo fatto da persone in carne e do ossa quindi non infallibili per definizione


Ma infatti è TUTTO esattamente come dici tu, di qualunque cosa si tratti.
Saturn09 Giugno 2026, 11:59 #10
Dai che stasera alle 19,00 escono le patch mensili per tutti i Windows...

...domani faremo un nuovo confronto con Linux !

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^