Neue Linux-Kernel-Sicherheitslücke „ssh-keysign-pwn“ ermöglicht Root-Zugriff bei gängigen Distributionen

Die Kurzfassung

Was: Eine lokale Rechteausweitung unter Linux in __ptrace_may_access(), informell als „ssh-keysign-pwn“ (oder „chage_pwn“, nach dem PoC aus der Überschrift) bezeichnet. Zum Zeitpunkt der Veröffentlichung wurde noch keine CVE-Nummer vergeben.

Auswirkungen: A öffentlicher Proof of Concept erhöht zuverlässig die Berechtigungen eines lokalen Benutzers ohne Root-Rechte auf Root, indem SUID-Binärdateien über dieses Sicherheitslücken ausgenutzt werden: chage auslaufen /etc/shadow, ssh-keysign die privaten SSH-Hostschlüssel offenzulegen.

Status: Die Korrektur im Vorfeld (Commit 31e62c2) erschien im selben Zeitfenster wie der Öffentliche Bekanntmachung auf oss-security. Es wurde noch keine CVE-Nummer vergeben, der Qualys-Sicherheitshinweis wurde noch nicht veröffentlicht, und es liegt noch kein CVSS-Wert vor. KernelCare hat Patches ohne Neustart für Ubuntu 22.04 (Jammy), Debian 11 (im ePortal) und die EL9-Familie (in den Repositories „test“ und „main“) bereitgestellt, RHEL 8/Rocky Linux 8 (im Test-Feed).

Schweregrad: Lokaler Vektor, keine Berechtigungen erforderlich, keine Benutzerinteraktion, keine spezielle Konfiguration. Der öffentliche PoC funktioniert sofort auf Debian 11/12/13, Ubuntu 22.04/24.04/26.04, Arch, Raspberry Pi OS Bookworm sowie den EL9- und EL10-Familien. EL8 und Ubuntu 20.04 sind anfällig, benötigen jedoch einen angepassten PoC. EL7 auf dem 3.10-Kernel ist nicht betroffen.

Warum dies wichtig ist: Da der Exploit auf gängige SUID-Binärdateien abzielt und weder Sonderrechte noch eine Interaktion des Benutzers erfordert, sollten anfällige Linux-Mehrbenutzersysteme als unmittelbar gefährdet betrachtet werden.

Mach das jetzt: Yama festziehen ptrace_scope auf Servern (ein sysctl, reversibel). KernelCare Kunden sollten auf die Veröffentlichung des Test-Feeds achten. Nachstehend finden Sie Befehle zur Problembehebung sowie Anweisungen zur Patch-Installation ohne Neustart.

Die Langfassung

Heute Morgen tauchte auf GitHub ein Root-Exploit für den Linux-Kernel auf – ohne CVE-ID, ohne Hinweis des Forschers, der die Schwachstelle entdeckt hatte, und mit einem öffentlichen Proof-of-Concept, der auf einem Standard-Debian- oder Ubuntu-Rechner funktioniert. Der Fehler befindet sich in __ptrace_may_access(). Der Fix wurde im gleichen Zeitfenster in den Upstream-Kernel integriert – eine gute Nachricht, nur dass niemand außerhalb der Kernel-Teams der Distributionen ihn erst in einigen Tagen erhalten wird.

Hier die genauen Details zur Zeitachse: Jann Horn schlug bereits 2020 eine entsprechende Lösung für diesen Fehler vor. Diese wurde jedoch nicht übernommen. Die Ursache blieb fünf Jahre lang in jedem stabilen Kernel-Zweig unentdeckt, bis ein Forscher von Qualys sie wiederentdeckte und ein zweiter Forscher innerhalb weniger Stunden nach der Veröffentlichung im Upstream zwei funktionierende Exploits im Repository „ssh-keysign-pwn“ veröffentlichte.

Der „rebootless“-Patch von KernelCare befindet sich derzeit in der Entwicklung. Bis zur Veröffentlichung gibt es einen sysctl-Eintrag, der den öffentlichen PoC sofort stoppt. Hier erfährst du, was gerade passiert und was du heute tun kannst.

So funktioniert der Exploit

Eine Überarbeitung aus dem Jahr 2017 von __ptrace_may_access() (Commit bfedb589, v4.10-rc1) kehrte die Zugriffsprüfung stillschweigend um, wenn eine Aufgabe mm ist NULL. Der Code vor der Umgestaltung verweigerte in diesem Zustand den Zugriff. Der umgestaltete Code lässt den Zugriff zu.

Beim Beenden des Prozesses gibt es ein Zeitfenster im Mikrosekundenbereich, in dem task->mm ist bereits gelöscht, aber die Dateideskriptoren der Aufgabe sind noch aktiv. Der öffentliche PoC lässt einen SUID-Prozess durch dieses Zeitfenster laufen, indem er pidfd_open und pidfd_getfd, mit zwei vorgefertigten Zielen im Repo: chage auslaufen /etc/shadowund ssh-keysign um private SSH-Hostschlüssel offenzulegen. Die gemeldete Trefferquote liegt bei 100 bis 2.000 generierten Instanzen pro Erfolg.

Jann Horn schlug 2020 eine entsprechende Korrektur vor (v1, v2). Diese wurde nicht übernommen, und der Fehler blieb bestehen.

Wer ist betroffen?

Die Regression wurde in die stabile Version 4.4.40 zurückportiert, sodass standardmäßig praktisch jeder moderne Kernel einer Distribution, die nicht auf EL7 basiert, davon betroffen ist. Drei Gruppen:

Der öffentliche PoC funktioniert sofort:

• Debian 11, 12, 13
• Ubuntu 22.04, 24.04, 26.04
• Arch Linux (aktuelle Version)
• Raspberry Pi OS Bookworm
• CentOS Stream 9, AlmaLinux 9, RHEL 9, Oracle Linux 9, Rocky Linux 9
• AlmaLinux 10, RHEL 10

Sicherheitslücke vorhanden, aber der PoC muss angepasst werden:

• EL8-Familie (RHEL 8, AlmaLinux 8, Rocky 8, Oracle Linux 8)
• Ubuntu 20.04

Nicht betroffen:

• Die EL7-Familie auf dem 3.10-Kernel – stammt aus der Zeit vor der Regression von 2017

Jetzt Maßnahmen ergreifen

Yama festziehen ptrace_scope. Der Exploit nutzt die Sicherheitslücke aus, indem er pidfd_getfd(). pidfd_getfd() Anrufe ptrace_may_access(…, PTRACE_MODE_ATTACH_REALCREDS), der den LSM-Hook am Ende von __ptrace_may_access. Ein Yama-Deny umgeht den Fehler unabhängig vom fehlerhaften mm-NULL-Fall-Through.

Das Übliche ptrace_scope=1 Die Standardeinstellung (in Debian/Ubuntu) reicht NICHT aus. Unter scope=1, ist die Anbindung von Eltern- an Kindprozesse zulässig. Der Angreifer startet den SUID-Prozess selbst, sodass er sind das übergeordnete Element. Du musst zu scope=2 oder scope=3.

Empfohlen: ptrace_scope=2 (Nur für Administratoren, zur Laufzeit vollständig rückgängig zu machen):

sudo sysctl -w kernel.yama.ptrace_scope=2

Nach der Installation des „rebootless“-Patches zurücksetzen:

sudo rm /etc/sysctl.d/99-ssh-keysign-pwn.conf

Stärker: ptrace_scope=3 (keine Anhänge für niemanden, ohne Neustart nicht rückgängig zu machen):

sudo sysctl -w kernel.yama.ptrace_scope=3

scope=3 ist eine Einbahnstraße bis zum Neustart: Der Kernel lehnt spätere Versuche ab, diesen Wert zu senken (sysctl -w kernel.yama.ptrace_scope=2 Ergebnisse EINVAL). Wähle diese Option nur, wenn du einen Neustart zur Rückgängigmachung akzeptieren kannst und wenn „root debug-attach“ (gdb -p, strace -p (als Root) gehört nicht zu Ihren üblichen Arbeitsabläufen.

Kompatibilität

• scope=2 bricht nicht privilegierte gdb -p / strace -p / perf trace --pid sowie Container-Debugging-Abläufe root behält die Verbindung bei, sodass die Fehlerbehebung durch den Administrator weiterhin funktioniert.
• scope=3 verhindert das Anhängen an den Debugger für alle Benutzer, einschließlich root.

KernelCare Rebootless Patch

KernelCare hat Patches ohne Neustart für Ubuntu 22.04 (Jammy), Debian 11 (im ePortal), die EL9-Familie (in den Feeds „test“ und „main“) sowie RHEL 8/Rocky Linux 8 (im Feed „test“) bereitgestellt.

Sobald es in den Test-Feed freigegeben wurde:

kcarectl --update --prefix test

Nach der Validierung wird der Patch beim nächsten geplanten Durchlauf bereitgestellt, oder Sie können ihn bei Bedarf abrufen:

kcarectl --update

Was man im weiteren Verlauf im Auge behalten sollte

• CVE-Zuweisung: (zum Zeitpunkt der Erstellung dieses Artikels keine)
• Qualys’ eigener Sicherheitshinweis, der voraussichtlich eine ausführlichere technische Beschreibung enthalten wird
• Aktualisierungen des Distributions-Kernels von Debian, Ubuntu und den Anbietern von EL9/10
• Neue Commits im öffentlichen Repository „ssh-keysign-pwn“ – die beiden aktuellen Ziele sind wahrscheinlich nicht die einzigen realistischen

Wir werden diesen Beitrag aktualisieren, sobald die CVE veröffentlicht wird und der KernelCare-Patch von der Test- in die stabile Version übergeht. Wenn Sie KernelCare nutzen, wird der Patch automatisch installiert, sodass Sie nichts weiter unternehmen müssen.

Wenn Sie noch kein KernelCare-Nutzer sind, ist jetzt ein guter Zeitpunkt, um zu erfahren, wie Patches ohne Neustart kritische Linux-Systeme schützen können, ohne dass Notfallwartungsfenster oder Ausfallzeiten erforderlich sind.

Erfahren Sie hier mehr über KernelCare →