ssh-keysign-pwn – PoC für einen Linux-0-Day, mit dem nicht privilegierte Nutzer root-eigene Dateien lesen können

• ssh-keysign-pwn ist ein PoC für eine Linux-Schwachstelle, mit der nicht privilegierte Nutzer root-eigene Dateien lesen können; betroffen seien Kernel vor 31e62c2ebbfd
• Der zentrale Bug besteht darin, dass __ptrace_may_access() die dumpable-Prüfung überspringt, wenn task->mm == NULL, und dass do_exit() exit_mm() vor exit_files() ausführt, wodurch ein Fenster entsteht, in dem Dateideskriptoren geöffnet bleiben
• In diesem Fenster ist pidfd_getfd(2) erfolgreich, wenn die uid des Aufrufers mit der des Zielprozesses übereinstimmt; dadurch lassen sich offene Dateideskriptoren eines Prozesses abrufen, der gerade beendet wird
• sshkeysign_pwn holt /etc/ssh/ssh_host_{ecdsa,ed25519,rsa}_key und nutzt den Ablauf aus, bei dem ssh-keysign.c Schlüssel mit Rechten 0600 öffnet und vor permanently_set_uid() mit EnableSSHKeysign=no beendet wird, wodurch offene fds zurückbleiben
• chage_pwn holt /etc/shadow und zielt auf die Exit-Race in dem Ablauf, bei dem chage -l <user> nach spw_open(O_RDONLY) mit setreuid(ruid, ruid) seine Rechte vollständig ablegt
• Die Ausführung erfolgt mit make und danach ./sshkeysign_pwn für Host-Schlüssel bzw. ./chage_pwn root zur Ausgabe des Inhalts von /etc/shadow auf stdout; laut Beschreibung gelingt der Treffer innerhalb von 100 bis 2000 Spawns
• Bestätigte Umgebungen sind Raspberry Pi OS Bookworm 6.12.75, Debian 13, Ubuntu 22.04 / 24.04 / 26.04, Arch und CentOS 9
• Als kontrollierte Ziel-PoC öffnet vuln_target.c /etc/shadow und legt dann die Rechte ab; exploit_vuln_target.c zeigt EPERM, solange das Ziel noch lebt, und fd-Hijacking nach SIGKILL
• Die Schwachstelle wurde von Qualys gemeldet und von Linus am 2026-05-14 behoben; außerdem wird darauf hingewiesen, dass Jann Horn bereits im Oktober 2020 auf eine Form des FD-Hijackings hingewiesen hatte
• Das README verweist auf den NVD-Eintrag https://nvd.nist.gov/vuln/detail/CVE-2026-46333

[GN⁺]

Lobste.rs-Kommentare

• Das Deaktivieren von ptrace allein reicht nicht aus. Wegen der Commit-Message und des Funktionsnamens ist das leicht missverständlich, aber ptrace_may_access wird über mehrere Pfade aufgerufen, und auch dieser Proof of Concept (PoC) verwendet tatsächlich kein ptrace
  Geeignete Gegenmaßnahmen gibt es kaum; im Moment scheint es nur darauf hinauszulaufen, entweder 1) nur schwach auf genau diesen speziellen PoC zu reagieren, indem man das Ausführungs-Bit von /usr/lib64/misc/ssh-keysign vollständig entfernt, oder 2) mit eBPF oder systemtap so etwas wie eine Sperre für pidfd_getfd einzurichten. Ersteres ist höchstens etwas, das man in Betracht zieht, wenn man weder den Kernel patchen noch den Dienst beenden kann und jetzt sofort schlafen muss
  Ich habe den PoC nicht geprüft, und wie immer ist Vorsicht geboten, wenn man beliebige PoCs aus dem Internet ausführt
  Das Qualys-Advisory ist noch nicht veröffentlicht, und Qualys hatte bereits erklärt, die Verteilung über linux-distros wegen der Linux-Kernel-Sicherheitsrichtlinie mit großem Bedauern einzustellen. Die Lage ist rauer geworden, weil LLMs aus verdächtig aussehenden Fix-Commits sehr schnell PoCs erzeugen können; früher hätte man vermutlich noch ein paar Tage warten können
  Qualys ist ein wirklich großartiges Team, deshalb ist es schade, dass sie diesmal nicht den richtigen Moment bekommen haben, das selbst ordentlich anzukündigen. Wenn es veröffentlicht wird, wird es sicher ein hervorragendes Advisory sein
  openssh ist nur ein bequemes Ziel für diesen Angriff und trägt keine Schuld; man könnte auch andere setuid-Binärdateien als Ziel wählen

  • Laut dem Qualys-Update verhindert das Setzen von /proc/sys/kernel/yama/ptrace_scope auf 2 (admin-only attach) oder 3 (no attach) alle bekannten Exploits. Theoretisch könnte es aber andere Ausnutzungswege geben
  • Als schnelle Gegenmaßnahme habe ich das LLM Opus ein systemtap-Skript zum Blockieren von pidfd_getfd schreiben lassen; das Ergebnis gibt es hier. Es muss mit stap -g block_pidfd_getfd.stp ausgeführt werden, und wie bei allem aus dem Internet sollte man das Skript vor der Ausführung unbedingt prüfen
  • Gibt es einen Link zur linux-distros-Ankündigung? Ich kann nichts dazu finden

• Ich wünschte, der Kernel würde damit aufhören, sich durch öffentliche Commits von Fixes im Main-Branch selbst 0-days offenzulegen. Im Commit steht sogar „Reported-by: Qualys“, also ist klar, dass es sich um einen Security-Fix handelt

  • Letzte Woche gab es dazu bereits eine größere Debatte
    Greg K-H schrieb, das Kernel-Sicherheitsteam könne nicht auswählen, wer Security-Fixes vorab erhält, weshalb am Ende niemand eine Vorab-Offenlegung bekommt
  • Und wie sollte man es stattdessen machen?

• Das ist kein SSH-Problem, sondern ein Linux-Problem. Der Titel sollte das auch so zeigen

  • Ich stimme zu, dass der Titel irreführend ist, aber ich hatte keine bessere Idee, wie man ihn nennen sollte. Ich kann ihn noch ändern, also wären Vorschläge willkommen
  • Stimmt, aber gleichzeitig wäre ein System, auf dem diese Option wie standardmäßig deaktiviert ist, nicht anfällig für das Abgreifen des Host-Schlüssels gewesen, wenn ssh-keysign vor dem Öffnen des privaten Host-Schlüssels zuerst EnableSSHKeysign=yes geprüft hätte. Es überrascht mich, dass ssh-keysign diese Option nicht als Erstes prüft

• Der Proof of Concept ist erfreulich kurz, und meine Geräte waren tatsächlich ebenfalls verwundbar
  Offenbar ermöglicht das unter bestimmten Bedingungen den Zugriff auf Dateideskriptoren, die von setuid-Programmen geöffnet wurden. Ich sehe keinen Grund, warum das auf Lesezugriff beschränkt sein sollte, und es scheint sich zu einer lokalen Privilegieneskalation (LPE) ausbauen zu lassen, bei der man keine Hashes knacken muss
  Diesen speziellen PoC kann man mit chmod -x /usr/lib/openssh/ssh-keysign /usr/bin/chage außer Gefecht setzen. Den ssh-keysign-Pfad muss man eventuell anpassen; siehe auch die Manpage. Das behebt aber nicht das Kernproblem, und es dürfte umgehbar sein. Soweit ich weiß, gibt es keine anderen Gegenmaßnahmen
  Behoben wurde das Problem in ptrace: slightly saner 'get_dumpable()' logic, und genau dadurch wurde es öffentlich. Das ist gerade einmal 10 Stunden her
  Es gibt auch eine öffentliche Mitteilung von Qualys an oss-security; dort heißt es, das Advisory werde noch nicht veröffentlicht, um Distributionen und Nutzern Zeit zum Patchen zu geben. Das dürfte ziemlich interessant werden; bis dahin kann man sich die Erklärung von Brad Spengler von grsecurity ansehen. Dieser Tweet scheint die Entwicklung dieses PoC ausgelöst zu haben

  • Ich habe versucht, den PoC auszuführen, aber das Rennen nicht gewonnen. Das Paar exploit_vuln_target/vuln_target funktionierte allerdings problemlos. Nicht besonders gut

• Realistisch betrachtet scheint das nur Systeme zu betreffen, auf denen es bereits einen nicht privilegierten Account gibt. Das heißt: Wenn es keinen gültigen Login gibt, kann man damit bei einem Server mit im Internet exponiertem SSH nicht direkt Remote Code Execution erreichen, richtig?

  • Richtig. Eine Ausnahme wäre allerdings, wenn man über einen anderen Dienst RCE erlangen kann, wie bei der vor ein paar Tagen erschienenen nginx-Remote-Code-Execution