CVE-2026-23111 Defensives Validierungsskript

Übersicht

CVE-2026-23111 ist eine Schwachstelle im Linux-Kernel in nf_tables, die von einem unprivilegierten Benutzer zur lokalen Privilegienausweitung auf Systemen ausgenutzt werden kann, auf denen Benutzer-Namespaces und nftables verfügbar sind.[1][2] Öffentliche Sicherheitsempfehlungen von Herstellern und Behörden beschreiben sie als lokales Problem, das Linux-Distributionen betrifft, und betonen das Patchen als primäre Lösung.[3][4]

Dieses Repository enthält ein defensives Validierungsskript, das dabei helfen soll zu bewerten, ob ein Host die mit dieser CVE verbundenen technischen Bedingungen aufweist, ohne einen Privilege-Escalation-Exploit bereitzustellen. Es prüft relevante Kernel- und Laufzeitbedingungen, lädt optional das Modul nf_tables für vollständige Funktionstests, versucht einen kontrollierten nicht-privilegierten Validierungspfad mit unshare und nft, sammelt lokale Diagnose-Traces und klassifiziert den Host in operative Bewertungen wie „wahrscheinlich sicher“, „durch lokale Richtlinie blockiert“ oder „exponierter Pfad verfügbar“.[1][5]

Was die CVE ist

Laut NVD ist CVE-2026-23111 eine Schwachstelle im Linux-Kernel in nf_tables, die als Logikfehler-Behebung in netfilter gelöst wurde und auf betroffenen Konfigurationen von einem unprivilegierten Benutzer über Benutzer-Namespaces und nftables zur lokalen Privilegienausweitung ausgenutzt werden kann.[1] Ubuntus Sicherheitshinweis beschreibt denselben übergeordneten Ausnutzungspfad und verfolgt betroffene und behobene Paketzustände je Release.[2]

Red Hat gibt an, dass ein lokaler Benutzer mit niedrigen Privilegien das Problem ausnutzen kann, um einen Denial of Service zu verursachen oder möglicherweise eine Privilegienausweitung zu erreichen, und dokumentiert einen Minderungspfad, der darauf basiert, das Laden des Moduls nf_tables zu verhindern, wenn dies betrieblich akzeptabel ist.[3] Auch die nationale Beratung des Canadian Centre for Cyber Security verweist betroffene Organisationen auf Hersteller-Updates und erwähnt die Regenerierung von initramfs, wenn Minderungsmaßnahmen zur Modul-Blockierung verwendet werden.[4]

Was das Skript tut

Das Skript ist für die defensive Expositionsbewertung gedacht, nicht für die Ausnutzung. Es wurde entwickelt, um:

• den laufenden Kernel, die Distributionsfamilie und relevante Laufzeit-Härtungseinstellungen zu identifizieren.
• zu prüfen, ob CONFIG_USER_NS und CONFIG_NF_TABLES vorhanden zu sein scheinen.[1]
• kernel.unprivileged_userns_clone und user.max_user_namespaces zu untersuchen, um abzuschätzen, ob unprivilegierte Benutzer-Namespaces verfügbar sind.
• zu erkennen, ob eine harte Modprobe-Verweigerung (install nf_tables /bin/false) oder eine schwache Blacklist für das Modul nf_tables vorhanden ist.
• das RPM-Changelog des Hersteller-Kernels auf einen CVE-2026-23111-Backport-Eintrag zu prüfen (nur RHEL-Familie).
• vor jeder Modul-Interaktion /proc/kallsyms auf das anfällige Symbol (nft_map_catchall_activate) gegenüber dem Symbol nach dem Patch (nft_catchall_set_activate) zu prüfen.
• optional nf_tables über modprobe zu laden, wenn angegeben ist (siehe unten), und es beim Beenden automatisch zu entladen.

Das Skript speichert Logs in einem Unterverzeichnis des Skriptverzeichnisses und entfernt sie standardmäßig, sofern nicht --keep-logs verwendet wird.

Richtlinie zum Laden von Modulen

Standardmäßig lädt das Skript niemals nf_tables. Wenn das Modul beim Start des Skripts nicht bereits geladen ist, werden alle funktionalen nft-Tests übersprungen und die Bewertung wird ausschließlich aus Kernelversion, kallsyms-Fingerprint, Modprobe-Konfiguration, RPM-Changelog und Sysctl/LSM-Richtlinienhinweisen abgeleitet.

Diese konservative Standardeinstellung vermeidet eine unbeabsichtigte Erweiterung der Angriffsfläche auf Produktionssystemen. Um vollständige Funktionstests auf einem kontrollierten oder instrumentierten System zu ermöglichen, verwenden Sie --allow-load-module als root (siehe unten).

Verwendung

# Default — no module loading, policy-evidence-only verdict
./check_cve_2026_23111.sh
./check_cve_2026_23111.sh --color
./check_cve_2026_23111.sh --keep-logs
./check_cve_2026_23111.sh --color --keep-logs

# Full functional test — loads (and unloads) nf_tables, requires root
sudo ./check_cve_2026_23111.sh --allow-load-module
sudo ./check_cve_2026_23111.sh --allow-load-module --color --keep-logs

Optionen

Wann --allow-load-module verwendet werden sollte

Verwenden Sie --allow-load-module, wenn Sie die Bewertung mit der höchsten Aussagekraft auf einer isolierten, nicht für die Produktion bestimmten oder zweckgebauten Test-VM benötigen. Typische Szenarien:

• Ein Kernel im anfälligen Bereich wird validiert, bevor der Hersteller-Fix bereitgestellt wird.
• Das Testsystem hat KASAN oder andere Instrumentierung aktiviert, und Sie möchten Kernel-Traces beobachten.
• Das Modul wird auf dem Zielhost nicht verwendet, und für Audit-Nachweise ist eine vollständige Ende-zu-Ende-Pfadprüfung erforderlich.

Verwenden Sie --allow-load-module nicht auf Produktionshosts, auf denen nf_tables absichtlich blockiert ist oder wo das Laden gegen eine Härtungsrichtlinie verstoßen würde.

Sicherheitsprüfungen für --allow-load-module

Vor dem Versuch, das Modul zu laden, erzwingt das Skript die folgenden Prüfungen und beendet sich mit einem Fehler, wenn eine davon fehlschlägt:

1. Eine harte Modprobe-Verweigerung (install nf_tables /bin/false) darf nicht in /etc/modprobe.d/ vorhanden sein.
2. modprobe muss auf dem System verfügbar sein.
3. Das Skript muss als root (uid 0) ausgeführt werden.

Wenn das Modul vom Skript erfolgreich geladen wurde, wird beim Beenden modprobe -r nf_tables über den cleanup()-Trap aufgerufen, unabhängig davon, wie das Skript endet (Erfolg, Fehler oder CTRL+C).

Bewertungsmodell

Das Skript verwendet operative Bewertungen anstelle von Exploit-Ergebnissen:

Diese Bewertungen sollen die Patch-Priorisierung und die defensive Sichtung unterstützen und nicht die Validierung des Hersteller-Paketstatus ersetzen.

Kernelversionsabdeckung

Das Skript gleicht den laufenden Kernel mit den dokumentierten Upstream-Fixpunkten ab:

Empfohlene Minderungsmaßnahmen

Die primär empfohlene Maßnahme ist die Installation des vom Hersteller gepatchten Kernel-Updates und ein Neustart in den korrigierten Kernel.[2][3][4] Da die Ausnutzung von der lokalen Kernel-Angriffsfläche abhängt, kann zusätzliche Härtung die Exposition verringern, während das Patchen geplant oder validiert wird.[5][6]

Prioritäre Maßnahmen

1. Kernel patchen mithilfe der offiziellen Distributionsempfehlung und in die behobene Version neu starten.[2][3][4]
2. Unprivilegierte Benutzer-Namespaces einschränken, wo es die Geschäftsanforderungen erlauben, da der dokumentierte Angriffspfad davon abhängt, dass sie unprivilegierten Benutzern zur Verfügung stehen.[1][5][6]
3. Das Laden von nf_tables deaktivieren oder blockieren, wenn das System keine nftables-Funktionalität benötigt und die Änderung auf betriebliche Auswirkungen hin validiert wurde.[3][4]
4. Privilegierte Netzwerk-Fähigkeiten einschränken, wie etwa Zugriffspfade, die CAP_NET_ADMIN betreffen, und die Anzahl der Konten reduzieren, die den Firewall-Zustand manipulieren können.[5]

Beispielhafte Härtungsschritte

Unprivilegierte Benutzer-Namespaces einschränken:

echo 'kernel.unprivileged_userns_clone=0' > /etc/sysctl.d/99-cve-2026-23111.conf
echo 'user.max_user_namespaces=0' >> /etc/sysctl.d/99-cve-2026-23111.conf
sysctl --load /etc/sysctl.d/99-cve-2026-23111.conf

Das Laden des Moduls nf_tables blockieren, wenn es betrieblich sicher ist:

echo 'install nf_tables /bin/false' > /etc/modprobe.d/disable-nf_tables.conf
rmmod nf_tables 2>/dev/null || true

Wenn eine Maßnahme zum Blockieren des Modulladens verwendet wird, empfehlen einige Anleitungen, initramfs zu regenerieren, damit das blockierte Modul nicht während des frühen Bootvorgangs geladen wird.[4]

Ubuntu-spezifischer Hinweis

Ubuntu dokumentiert AppArmor-basierte Einschränkungen für unprivilegierte Benutzer-Namespaces als Möglichkeit, die Angriffsfläche zu reduzieren, und nicht als vollständigen Ersatz für Kernel-Fixes.[6] Ein Host kann bei Laufzeittests weniger exponiert erscheinen, weil der Angriffspfad lokal blockiert ist, während die langfristige Behebung weiterhin die Installation des vom Hersteller gepatchten Kernel-Pakets erfordert.[2][6] Das Skript validiert die Wirksamkeit der AppArmor-Einschränkungen, indem es einen tatsächlichen unshare --user-Aufruf versucht und prüft, ob CAP_NET_ADMIN innerhalb eines User+Net-Namespace funktionsfähig ist.

Red Hat-spezifischer Hinweis

Red Hat führt ausdrücklich das Verhindern des Ladens des Moduls nf_tables als Minderungsmaßnahme für CVE-2026-23111 auf, wenn diese Änderung für die Umgebung geeignet ist.[3] Das Skript erkennt diese Konfiguration über check_modprobe_deny() und unterscheidet zwischen einer harten Verweigerung (install nf_tables /bin/false, die das Laden auf Abruf blockiert) und einer schwachen Blacklist (die dies nicht tut). Auf Systemen der RHEL-Familie untersucht das Skript außerdem das RPM-Changelog des laufenden Kernels auf einen CVE-2026-23111-Backport-Eintrag, was eine herstellerbestätigte Bewertung unabhängig von der Upstream-Versionsnummer ermöglicht.

Offizielle Referenzen

• NVD: CVE-2026-23111 Details [1]
• Ubuntu Security: CVE-2026-23111 [2]
• Red Hat Security: CVE-2026-23111 [3]
• Sicherheitsempfehlung des Canadian Centre for Cyber Security: AL26-011 [4]
• Übersicht zu Ubuntus AppArmor-Einschränkung für Benutzer-Namespaces: Understanding AppArmor User Namespace Restriction [6]

Umfang und Sicherheit

Diese README und das zugehörige Skript sind für die defensive Validierung, Bestandsaufnahme und Minderungsplanung gedacht. Sie ersetzen keine Hersteller-Anleitungen, paketbezogene Verifizierung oder standardmäßige Patch-Management-Prozesse und sollten nicht als Ersatz für die Anwendung der offiziellen Fixes verwendet werden, die in den verlinkten Sicherheitsempfehlungen beschrieben sind.[2][3][4]

📚 Repository für Bildungs- und Sicherheitsforschung

Ein Repository zum Lernen, Testen und Erforschen von Cybersicherheitskonzepten in kontrollierten Umgebungen.

⚠️ Sicherheits- und Rechtshinweis

Zweck

Dieses Repository ist ausschließlich für pädagogische und autorisierte Sicherheitsforschung bestimmt.

Es wurde entwickelt, um Benutzern das Lernen über Folgendes zu ermöglichen:

• Sicherheitsschwachstellen
• Sandbox- und Isolationskonzepte
• Sichere Codierung und defensive Praktiken

Nur autorisierte Nutzung

Verwenden Sie dieses Repository nur in Umgebungen, in denen Sie die Berechtigung dazu haben, wie zum Beispiel:

• Persönliche Labore oder virtuelle Maschinen
• Docker- oder isolierte Umgebungen
• Autorisierte Penetrationstests
• Cybersicherheitsschulungen oder akademische Forschung

Unautorisierte oder illegale Nutzung ist strengstens untersagt.

Keine Haftung

Der Autor und die Mitwirkenden sind nicht verantwortlich für Schäden, Missbrauch, rechtliche Probleme oder Verluste, die durch dieses Projekt verursacht werden.

Durch die Nutzung dieses Repositorys stimmen Sie zu, dass:

• Sie für Ihre eigenen Handlungen verantwortlich sind
• Sie es legal und ethisch verwenden werden
• Das Projekt ohne Gewährleistung bereitgestellt wird

Ethische Nutzung

Dieses Projekt ist gedacht für:

• Defensive Sicherheitsforschung
• Cybersicherheitsausbildung
• Sensibilisierung für Schwachstellen
• Forschung an sicheren Systemen und Software

Bitte befolgen Sie Praktiken der verantwortungsvollen Offenlegung und halten Sie alle geltenden Gesetze ein.

Kontakt

Für verantwortungsvolle Offenlegung oder Zusammenarbeit kontaktieren Sie den Repository-Betreuer über GitHub.