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?
Schon klar. Alles andere wäre für eine Software, die mit dem Anspruch kommt, VMware produktiv zu ersetzen der Todesstoß.
Ich habe hier einen Testcluster, der aus zusammengewürfelter Alt-Hardware (größtenteils ehemalige ESXi-Hosts) besteht und mit 7er Kernels die lustigsten Kernel-Fehler z.T mit spontanem Reboot bringt. Nicht startendes Win11 ist auch lustig.
Im Proxmox-Forum geht es gerade nett ab.
Den produktiven Cluster werde ich definitiv nicht anfassen, schon allein deswegen nicht, weil heute Backupfenster ist.
Also viel Lärm um nichts.
Dann ist es eben weniger ein Brainer als unter Windows. Ich finde auch Produktivmaschinen sollten im Regelfall redundant ausgelegt sein, sodass ein Update einer Maschine den produktiven Service nicht offline nimmt.
Danke für den Lacher, der war gut!
Siehe Artikel:
Ich verstehe den Originaltext da anders.
> Reported by Qualys, fixed by Linus 2026-05-14. Jann Horn flagged the FD-theft shape in October 2020. Six years.
Das sagt für mich aus, dass die Schwachstelle seit 2026-05-14 bekannt und behoben ist. Die Schwachstelle wurde im Oktober 2020, also vor sechs Jahren, in den Quellcode aufgenommen und schlummerte seit dem da.
Dafür spricht auch, dass die CVE Nummer eine aus 2026 ist. Die Schwachstelle ist also mitnichten seit sechs Jahren bekannt.
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 👍
Es fehlen aber immer noch fixes für CVE-2026-46300
https://security-tracker.debian.org/tracker/CVE-2026-46300
korrekt, erst jetzt am ausrollen, zB bei Debian DSA-6295-1 :
CVE-2026-23171, CVE-2026-43503, CVE-2026-46300
Beim Schreiben haben SID und Trixie schon gelistet.
security-tracker[.]debian.org/tracker/source-package/linux
Naja es betrifft Systeme auf denen der potentielle Angreifer lokalen Zugriff hat, das dürfte 99.99% aller System ausschliessen.
Ja und nein. Sich Zugriff als user zu verschaffen ist einfacher als root. Und wenn man dann seine ausweiten kann…
Die meisten Services laufen nicht mit root aber auf deren Benutzer kann durch andere Schwachstellen Zugriff erlangt werden. Und dann eben auf root ausgeweitet.
Ganz so einfach ist das eben nicht.