Red Hat dichiara che un utente locale con privilegi bassi potrebbe sfruttare il problema per causare denial of service o potenzialmente ottenere l'escalation dei privilegi, e documenta un percorso di mitigazione basato sull'impedire il caricamento del modulo nf_tables quando ciò è operativamente accettabile.[3] Anche le linee guida a livello nazionale del Canadian Centre for Cyber Security indirizzano le organizzazioni colpite agli aggiornamenti dei vendor e menzionano la rigenerazione dell'initramfs quando vengono utilizzate mitigazioni di blocco dei moduli.[4]

Cosa fa lo script

Lo script è pensato per la valutazione difensiva dell'esposizione, non per lo sfruttamento. È progettato per:

• Identificare il kernel in esecuzione, la famiglia di distribuzione e le relative impostazioni di hardening del runtime.
• Verificare se CONFIG_USER_NS e CONFIG_NF_TABLES risultano presenti.[1]
• Ispezionare kernel.unprivileged_userns_clone e user.max_user_namespaces per stimare se gli user namespace non privilegiati sono disponibili.
• Rilevare se è in atto un deny modprobe rigido (install nf_tables /bin/false) o una blacklist debole per il modulo nf_tables.
• Controllare il changelog RPM del kernel del vendor per una voce di backport di CVE-2026-23111 (solo famiglia RHEL).
• Rilevare l'impronta di /proc/kallsyms per il simbolo vulnerabile (nft_map_catchall_activate) rispetto al simbolo post-patch (nft_catchall_set_activate) prima di qualsiasi interazione con il modulo.
• Caricare opzionalmente nf_tables tramite modprobe quando viene specificato --allow-load-module (vedi sotto) e scaricarlo automaticamente all'uscita.
• Eseguire un passaggio di validazione vincolato unshare -U -n --map-root-user + nft quando il modulo è caricato, e registrare stdout, stderr e i log recenti del kernel.
• Verificare che unshare --user crei effettivamente un namespace e che CAP_NET_ADMIN sia funzionante al suo interno, per confermare se le restrizioni AppArmor o SELinux sono realmente efficaci.
• Evidenziare se i controlli di sicurezza locali come AppArmor o SELinux sembrano bloccare il percorso testato.[6]
• Produrre un output orientato ai verdetti con evidenziazione opzionale a colori per un triage più semplice.

Lo script salva i log in una sottodirectory della directory dello script e li rimuove per impostazione predefinita a meno che non venga usato --keep-logs.

Policy di caricamento del modulo

Per impostazione predefinita lo script non carica mai nf_tables. Se il modulo non è già caricato all'avvio dello script, tutti i test funzionali nft vengono saltati e il verdetto deriva esclusivamente dalla versione del kernel, dall'impronta kallsyms, dalla configurazione di modprobe, dal changelog RPM e dalle evidenze di policy sysctl/LSM.

Questa impostazione predefinita conservativa evita di espandere involontariamente la superficie d'attacco sugli host di produzione. Per abilitare test funzionali completi su un sistema controllato o strumentato, usa --allow-load-module come root (vedi sotto).

Utilizzo

Opzioni

Quando usare --allow-load-module

Usa --allow-load-module quando hai bisogno del verdetto con la massima affidabilità su una VM di test isolata, non di produzione o dedicata. Scenari tipici:

• Un kernel nell'intervallo vulnerabile viene validato prima di implementare la correzione del vendor.
• Il sistema di test ha KASAN o altra strumentazione abilitata e vuoi osservare le tracce del kernel.
• Il modulo non è in uso sull'host target e per le evidenze di audit è richiesto un controllo completo end-to-end del percorso.

Non usare --allow-load-module su host di produzione in cui nf_tables è bloccato intenzionalmente o dove il suo caricamento violerebbe una policy di hardening.

Controlli di sicurezza per --allow-load-module

Prima di tentare di caricare il modulo, lo script applica i seguenti controlli ed esce con un errore se uno di essi fallisce:

1. Un deny modprobe rigido (install nf_tables /bin/false) non deve essere presente in /etc/modprobe.d/.
2. modprobe deve essere disponibile sul sistema.
3. Lo script deve essere eseguito come root (uid 0).

Se il modulo viene caricato con successo dallo script, modprobe -r nf_tables viene chiamato all'uscita tramite il trap cleanup(), indipendentemente da come termina lo script (successo, errore o CTRL+C).

Modello di verdetto

Lo script usa verdetti operativi piuttosto che esiti di sfruttamento:

Questi verdetti sono pensati per supportare la prioritizzazione delle patch e il triage difensivo, non per sostituire la validazione dello stato dei pacchetti del vendor.

Copertura delle versioni del kernel

Lo script mappa il kernel in esecuzione rispetto ai punti di correzione upstream documentati:

Mitigazione consigliata

L'azione principale consigliata è installare l'aggiornamento del kernel corretto dal vendor e riavviare con il kernel corretto.[2][3][4] Poiché lo sfruttamento dipende dalla superficie d'attacco locale del kernel, un hardening aggiuntivo può ridurre l'esposizione mentre si pianifica o si valuta l'applicazione delle patch.[5][6]

Azioni prioritarie

1. Applicare la patch al kernel utilizzando il bollettino ufficiale della distribuzione e riavviare con la versione corretta.[2][3][4]
2. Limitare gli user namespace non privilegiati dove i requisiti aziendali lo consentono, perché il percorso d'attacco documentato dipende dalla loro disponibilità per gli utenti non privilegiati.[1][5][6]
3. Disabilitare o bloccare il caricamento di nf_tables se il sistema non richiede la funzionalità nftables e la modifica è stata validata per l'impatto operativo.[3][4]
4. Limitare le capability di rete privilegiate come i percorsi di accesso che coinvolgono CAP_NET_ADMIN e ridurre il numero di account che possono manipolare lo stato del firewall.[5]

Esempi di passaggi di hardening

Limitare gli user namespace non privilegiati:

Bloccare il caricamento del modulo nf_tables quando è operativamente sicuro:

Se viene utilizzata una mitigazione sul caricamento dei moduli, alcune linee guida raccomandano di rigenerare l'initramfs affinché il modulo bloccato non venga caricato durante l'avvio iniziale.[4]

Nota specifica per Ubuntu

Ubuntu documenta le restrizioni basate su AppArmor per gli user namespace non privilegiati come un modo per ridurre la superficie d'attacco piuttosto che come un sostituto completo delle correzioni del kernel.[6] Un host può apparire meno esposto nei test runtime perché il percorso d'attacco è bloccato localmente, mentre la remediation a lungo termine richiede comunque l'installazione del pacchetto kernel corretto dal vendor.[2][6] Lo script valida l'efficacia delle restrizioni AppArmor tentando un'invocazione reale di unshare --user e verificando se CAP_NET_ADMIN all'interno di un namespace user+net è funzionante.

Nota specifica per Red Hat

Red Hat elenca esplicitamente l'impedimento del caricamento del modulo nf_tables come mitigazione per CVE-2026-23111 quando tale modifica è appropriata per l'ambiente.[3] Lo script rileva questa configurazione tramite check_modprobe_deny() e distingue tra un deny rigido (install nf_tables /bin/false, che blocca il caricamento on-demand) e una blacklist debole (che non lo blocca). Sui sistemi della famiglia RHEL lo script ispeziona anche il changelog RPM del kernel in esecuzione per una voce di backport di CVE-2026-23111, consentendo un verdetto confermato dal vendor indipendente dal numero di versione upstream.

Riferimenti ufficiali

• NVD: Dettagli CVE-2026-23111 [1]
• Sicurezza Ubuntu: CVE-2026-23111 [2]
• Sicurezza Red Hat: CVE-2026-23111 [3]
• Bollettino del Canadian Centre for Cyber Security: AL26-011 [4]
• Panoramica sulle restrizioni degli user namespace di Ubuntu AppArmor: Understanding AppArmor User Namespace Restriction [6]

Ambito e sicurezza

Questo README e lo script associato sono pensati per la validazione difensiva, l'inventario e la pianificazione delle mitigazioni. Non sostituiscono le indicazioni del vendor, la verifica a livello di pacchetti o i processi standard di gestione delle patch, e non dovrebbero essere usati come sostituto dell'applicazione delle correzioni ufficiali descritte nei bollettini collegati.[2][3][4]

📚 Repository educativo di ricerca sulla sicurezza

Un repository per apprendere, testare e ricercare concetti di cybersecurity in ambienti controllati.

⚠️ Disclaimer di sicurezza e legale

Scopo

Questo repository è solo per ricerca sulla sicurezza educativa e autorizzata.

È progettato per aiutare gli utenti a conoscere:

• Vulnerabilità di sicurezza
• Concetti di sandbox e isolamento
• Pratiche di codifica sicura e difensive

Solo uso autorizzato

Usa questo repository solo in ambienti in cui hai il permesso, come:

• Lab personali o macchine virtuali
• Ambienti Docker o isolati
• Test di penetrazione autorizzati
• Formazione sulla cybersecurity o ricerca accademica

L'uso non autorizzato o illegale è severamente vietato.

Nessuna responsabilità

L'autore e i contributori non sono responsabili per qualsiasi danno, uso improprio, problema legale o perdita causati da questo progetto.

Usando questo repository, accetti che:

• Sei responsabile delle tue azioni
• Lo userai in modo legale ed etico
• Il progetto è fornito senza garanzia

Uso etico

Questo progetto è pensato per:

• Ricerca sulla sicurezza difensiva
• Formazione sulla cybersecurity
• Consapevolezza delle vulnerabilità
• Ricerca su sistemi e software sicuri

Segui le pratiche di responsible disclosure e rispetta tutte le leggi applicabili.

Contatti

Per responsible disclosure o collaborazione, contatta il maintainer del repository tramite GitHub.