DirtyDecrypt PoC erhöht das Risiko, Privilegien im Kernel in der Nähe der Mainline zu erhalten

Ein öffentlicher Konzepttest, der eine kürzlich korrigierte Schwachstelle im Linux-Kernel rxgk-Modul nutzt, erhöht das Risiko für Systeme, die Kernel sehr nahe am Hauptbaum laufen: die sogenannte Explosion DirtyDecrypt (oder DirtyCBC) ermöglicht es einem Angreifer mit lokalem Zugriff, in bestimmten Systemkonfigurationen root zu werden.

Die technische Wurzel des Problems, nach den Forschern, die die PoC veröffentlichten, ist ein Pagecache-Schreiben durch den Mangel einer Copy-on-write (COW)-Überprüfung auf der rxgk _ decrypt _ skb-Funktion verursacht: in einfachen Begriffen, Kernel-Code endete schreiben, wo es nicht auf gemeinsamen Daten sein sollte, die öffnet die Tür zu klettern Privilegien. Das V12-Team veröffentlichte die PoC und erklärt die Details im Projektarchiv ( V12 PoC: DirtyDecrypt), und die Beschreibung passt zu der im NVD erfassten Korrektur CVE-2026-31635.

Es ist wichtig, zwei Faktoren hervorzuheben, die Auswirkungen haben: erste, der Betrieb erfordert, dass der Kernel mit der aktivierten CONFIG _ RXGK-Option (d.h. RxGK-Unterstützung für AFS / rxrpc) kompiliert wird; daher betrifft er nur Distributionen, die dem Kernel vorgeschaltet folgen - zum Beispiel Fedora, Arch oder OpenSUSE Tumbleweed - oder Systeme mit benutzerdefiniertem Kernel einschließlich dieses Moduls. Zwei, der Vektor ist lokal: Ein Angreifer muss vorher Code auf der Maschine ausführen (z.B. durch ein kompromittiertes Benutzerkonto oder einen böswilligen Prozess mit eingeschränkten Fähigkeiten), um auf root zu klettern.

Die Existenz eines öffentlichen PoC ändert die Risikoschwelle: Bevor es ein korrigierter Ausfall im Vorfeld war, könnte nun jeder Gegner mit lokalem Zugriff und Grundwissen den Test erneut verwenden, um die vollständige Kontrolle des Systems zu übernehmen, wenn der Patch nicht angewendet wird. Dieses Muster ist nicht neu: in den letzten Wochen gab es wurzelbeklimmende Versagen derselben Familie (Dirty Frag, Fragnesia, Copy Fail) und Organismen wie die CISA haben bereits gewarnt und gelistete Schwachstellen im bekannten Katalog ausgenutzt ( CISA Bekannte ausgeschöpfte Schwachstellen), die eine Welle der aktiven Ausbeutung gegen Kernelvektoren zeigt.

Was Administratoren und Benutzer tun sollten: den Kernel aktualisieren die Version, die die Korrektur so bald wie möglich enthält; für Produktionsumgebungen, in denen eine sofortige Aktualisierung nicht praktisch ist, gelten vorübergehende Minderung und Kontrolle des lokalen Zugangs. Eine bisher verwendete Minderung gegen ähnliche Fehler ist, das Laden der Module zu vermeiden, indem eine Regel in / etc / modson.d erstellt wird, die ihre Installation verhindert, Download der Module und Entleerung von Blöcken; beachten Sie, dass diese Maßnahme IPsec und verteilte AFS-Dateisysteme brechen kann. Wenn Sie es annehmen, versuchen Sie es zuerst in kontrollierten Umgebungen und verstehen Sie die Auswirkungen auf die Konnektivität und Dienstleistungen.

Neben dem Patchen oder der Minderung, der Überprüfung der Telemetrie und der Systemintegrität: suchen Sie nach Zeichen der Eskalation von Privilegien oder Beharrlichkeit (unerwartete Rootsessions, neue SUID Binärsitzungen, abnormale Prozesse mit UID 0, Änderungen in / etc, verdächtige Einträge in dmesg oder syslog). Wenn Sie Kernel oder EDR-Erkennung haben, überprüfen Sie rxgk-bezogene Ereignisse oder atypische Pagecache-Operationen; wenn Sie diese Tools nicht haben, betrachten Sie die Bereitstellung von Steuerungen, die den lokalen Zugriff begrenzen und die Benutzer- und Servicesegmentierung verbessern.

Für Geräte, die große Flotten verwalten, Sie schätzen die Anwendung von Sicherheits-Backports, die von der Distribution angeboten werden, mit Livepatch-Diensten, wo sie verfügbar sind und priorisieren die Aktualisierung von Kernel in Bastionen oder Maschinen mit mehreren Benutzerkonten. Behalten Sie einen Reaktionsprozess, der die Isolation von verdächtigen Wirten, die Sammlung von Beweisen und die Wiederherstellung von sauberen bekannten Backups bei Bedarf beinhaltet.

Verantwortungsvolle Offenlegung und öffentliche Beweise erinnern uns auch an eine operative Lektion: Die Schwachstellen im Kernelraum, obwohl lokal, sind für Angreifer mit anfänglichem Zugriff sehr wertvoll und beschleunigen laterale Bewegung und Beharrlichkeit. Überprüfen Sie Kernel-Compilationsoptionen auf kritischen Maschinen (z.B. durch Beratung der Kernel-Konfiguration oder Lieferantenpakete, um zu sehen, ob CONFIG _ RXGK aktiv ist) hilft, Patches und Minderungen mit technischen Kriterien zu priorisieren.

Wenn Sie die technischen Ressourcen und die ursprünglichen Hinweise vertiefen möchten, sehen Sie das PoC des V12 Teams in GitHub ( https: / / github.com / v12-security / pcs / tree / main / dirtydecrypt) und der NVD-Eingang zur Korrektur ( https: / / nvd.nist.gov / vuln / detail / CVE-2026-31635) Die CISA-Basis ist eine nützliche Referenz für die Politik und die Überwachung von ausgenutzten Versagen im Ökosystem. https: / / www.cisa.gov / Wissens-exploited-vulnerabilities-catalog)

Kurz gesagt: Parken Sie bereits, reduzieren Sie den nicht-wesentlichen lokalen Zugang, überwachen Sie die Verpflichtungsindikatoren und erstellen Sie einen Antwortplan. Die öffentliche Verfügbarkeit von PoC erfordert, dass ohne Minderung oder Korrektur die Wahrscheinlichkeit der Ausbeutung rasch zunehmen wird.