Gerade ist eine neue Linux-Schwachstelle ssh-keysign-pwn (CVE-2026-46333) bekannt geworden. Diese ermöglicht Standardnutzern den Zugriff auf fremde Dateien, wozu normalerweise Root-Rechte erforderlich wären.
In den letzten Tagen wurden diverse Schwachstellen (Copy Fail, Dirty Frag, Fragnesia, siehe Links am Beitragsende) im Linux-Kernel bekannt. Zum 14. Mai 2026 wurde die neueste Schwachstelle "ssh-keysign-pwn" bekannt. Mit "ssh-keysign-pwn" können nicht privilegierte Benutzer Dateien lesen, die dem Root-Benutzer gehören. Es sind alle bisher noch nicht gepatchten Linux-Kernel-Versionen (vor 31e62c2ebbfd 14. Mai 2026) betroffen.
Leser Carsten wies in diesem Kommentar auf den Phoronix-Artikel Linux's Latest Vulnerability Allows Reading Root-Owned Files By Unprivileged Users hin (danke dafür, ich konnte aber nicht zeitnah reagieren). Obiger Tweet fasst einige Details zusammen:
- Es handelt sich eigentlich um eine seit sechs Jahren bekannte Schwachstelle, die auf eine Race-Condition in der Funktion __ptrace_may_access() zurück geht, und nun von Qualys offen gelegt wurde.
- Ein privilegierter Prozess (z. B. ssh-keysign oder chage) öffnet sensible Dateideskriptoren (FDs). Der Prozess pidfd_getfd() kann diese FDs während einer do_exit()-Operation, nach einem exit_mm() (mm=NULL), aber vor einem exit_files()-Aufruf, abgreifen.
Dies ermöglicht es nicht privilegierten lokalen Benutzern Dateien mit Root-Rechten zu lesen. Details zur Schwachstelle sind auf GitHub abrufbar, in der NIST-Beschreibung CVE-2026-46333 sind die Referenzseiten zu kernel.org verlinkt.
Laut Phoronix gibt es einen Patch, der das ptrace-Verhalten des Kernels anpasst und nach der Offenlegung durch Qualys seit dem 14. Mai 2026 im Hauptzweig des Linux-Kernels bereit steht. Alma Linux schreibt hier dass für deren Distribution ein Kernel-Patch verfügbar sei.
Weitere Informationen
Blog-Leser Norddeutsch hat am gestrigen Abend im Diskussionsbereich bereits auf den Beitrag Privilegienausweitung in Linux: Lokale Nutzer können fremde Dateien lesen bei heise hingewiesen, der eine Übersicht über die Schwachstelle gibt. Norddeutsch hat im Diskussionsbereich noch einige Informationen zur Schwachstelle eingestellt. So gibt es schon ein Proof of Concept (POC) und die Kernel-Maintainer der Distributoren benötigen noch etwas Zeit zur Verteilung der Patches. Ich ziehe mal den Kommentar von Norddeutsch hier in den Beitrag (da die Einträge im Diskussionsbereich zyklisch gelöscht werden).
Spitzname "_SiCk" verlinkt im OpenWall-Thread den Github-Account User 0xdeadbeefnetwork. Weiterhin auch den Blog afflicted.sh mit CopyFail 2 und CopyFail2 Electric Boogeloo auf Github. Dies ist nach Aussage dort eine "LPE via xfrm ESP-in-UDP MSG_SPLICE_PAGES no-COW fast path"; Genannt wird die Möglichkeit von "Page-cache write into any readable file".
Ebenso findet sich SSH-Keysign-PWN auf Github – Nach dortiger Aussage "Read root-owned files as an unprivileged user".Christopher@Heise wertet insbesondere ssh-keysign-pwn als kritisch, welche den "SSH-Private-Key der Maschine ausliest". Sensibel – und somit absolut verständlich. Weiterer Kreativität wären nach meinem Verständnis jedoch wenig Grenzen gesetzt. Als Workaround wird derzeit ein Hochsetzen vom "ptrace_scope auf "Level" 3" empfohlen. Dies über die CMD-Line (A). Dies ist nicht persistent. Eine reboot-feste Lösung (B) bietet eine Datei in /etc/sysctl.d/. Die Endung ".conf" ist zu beachten.
A) echo 3 > /proc/sys/kernel/yama/ptrace_scope
B) /etc/sysctl.d/ mit:
– zB Datei: 10-kernel-workaround.conf
– Zeile: kernel.yama.ptrace_scope=3 # (dein mitigation-comment)Ptrace ist ein Systemaufruf unter Linux. Dieser befähigt einen Prozess Daten über andere Prozesse abzufragen oder diese zu manipulieren. Idealerweise gilt dies nur wenn passende Rechte existieren – wie bei anderen Prozessen des Users mit identischer UID.
Die Auswirkung vom generellen Verbot auf "Level 3" nennt kernel.org hier. Die Level 0 bis 3 limitieren die Capability "CAP_SYS_PTRACE" und Aufruf "PTRACE_ATTACH". Der vorgeschlagene Level 3 unterbindet JEDEN Attach – sowohl via "PTRACE_ATTACH" als auch "PTRACE_TRACEME". Dies kann laut Doku ebenso nicht durch sysctl (also auch im Sinne von "zur Laufzeit") geändert werden.
Es unterbindet nach jetzigem Stand die Anwendbarkeit des Exploits. Er verhindert jedoch nicht nur Debugging sondern ebenso Tracing von/zwischen Prozessen und kann somit Funktionalität stören!
Bis dato nutze ich produktiv bisher mindestens "Level 1". Ich nutze (nur bis zum Kernelupdate) jetzt auf meinen Systemen "Level 3" – verbiete "Alles", benötige diese Funktionalität produktiv getestet jedoch auch nicht – und lasse Debugging oder Tracing einfach einige Tage sein…
Ähnliche Artikel:
Linux-Schwachstelle Copy Fail (CVE-2026-31431) erlaubt Rooting
Dirty Frag: Lokale Rechteausweitung im Linux-Kernel (CVE-2026-43284, CVE-2026-43500)
Fragnesia (CVE-2026-46300): Neue Linux-Schwachstelle ermöglicht Root-Rechte
MVP: 2013 – 2016
Informationen (von Linus Torvalds) dazu gibt es bei kernel.org zum Update auf 7.0.8. Bei Arch Linux hatte man kurz zuvor noch 7.0.7 entsprechend gepatcht und veröffentlicht, dort folgt in diesen Tagen Kernel-Update auf Kernel-Update in schneller Folge, die an den Chromium-Browser Angang des Jahres erinnert.
Link: https://cdn.kernel.org/pub/linux/kernel/v7.x/ChangeLog-7.0.8
Hat man eigentlich verlernt was Responsible Disclosure ist? Gut, dass Sicherheitslücken gefunden und gepatcht werden, aber man muss den bösen Buben doch nicht gleich jedes Detail liefern. Einfach mal ein paar Tage warten bis zumindest Patches bereitstehen. Bei mir entsteht der Eindruck in dieser Bubble geht es immer öfter auch darum der- oder diejenige zu sein, der oder die die Schwachstelle publik gemacht hat und für sich beanspruchen kann. Sehr fragwürdige Entwicklung.
Naja, warten wir auf Patches und schmeißen die Patch-Maschinerie erneut an. Immerhin ist das unter Linux ein No-Brainer.
Updates, die einen Reboot (da Kernel) von Produktivmaschinen erfordern sind nie ein No-Brainer, da sie entsprechende Wartungsfenster erfordern.
Immerhin ist es nicht so schlimm wie bei Proxmox gerade, die ohne Not und nur mit einem einfachen Forumspost den 7er Kernel sowie QEMU 11 zum Default machen – und auf jede Beschwerde zu geänderter Funktionalität nur antworten "schreib' doch einen Bugreport".
Ich hatte mir die Feiertage etwas anders vorgestellt.
Aber nur in test und no-subscription. Oder übersehe ich da was?
Siehe Artikel:
Für Debian Bookworm und Trixie sind seit gestern abend gepatchte Kernel verfügbar – der DSA-6274-1 bzw. DSA-6275-1 wurden um 19:53 über die Security-Announcement Liste verschickt.
Sehr gut 👍