Linux-Kernel-Schwachstellen werden nicht vorab an Distributionen gemeldet

• CopyFail, eine lokale Privilegieneskalations-Schwachstelle im Linux-Kernel, gehört in letzter Zeit zu den schwerwiegendsten „make-me-root“-Schwachstellen im Kernel (die normale Nutzer zu Root machen)
• Die Schwachstelle wurde mit einem bestimmten Commit in Kernel-Version 4.14 eingeführt und fällt zeitlich mit dem Zeitpunkt zusammen, an dem die In-Place-Optimierung für das im Exploit von CopyFail genutzte Modul authencesn hinzugefügt wurde
• Der Fix wurde in Kernel 6.18.22, 6.19.12 und 7.0 aufgenommen; 6.18.22 und 6.19.12 wurden am 11. April mit rückportiertem Fix veröffentlicht
• In den weiterhin weit verbreiteten Longterm-Kernels (6.12, 6.6, 6.1, 5.15, 5.10) ist der Fix jedoch nicht enthalten und er ist auch in der upstream stable queue noch nicht zu sehen
  • Da das Problem bereits 2017 eingeführt wurde, muss noch geprüft werden, ob auch diese älteren Longterm-Kernels betroffen sind
• Das Patch für den Fix lässt sich nicht clean apply auf ältere Kernel anwenden; wegen einiger API-Änderungen ist selbst ein Backport nur schwer mit Sicherheit umzusetzen
• In Umgebungen, in denen sofortiges Handeln nötig ist, kann als Übergangsmaßnahme ein Patch zum Deaktivieren des IPSec-Moduls authencesn eingesetzt werden; auch ohne IPSec-Expertise ist das „nicht perfekt, aber die weniger schlechte Wahl“
• Das eigentliche strukturelle Problem liegt also im Offenlegungsprozess für Linux-Kernel-Schwachstellen selbst:
  • Linux-Kernel-Schwachstellen werden den einzelnen Distributionen nicht vorab gemeldet, sofern die meldende Person nicht selbst die Mailingliste linux-distros (ein nicht öffentlicher Kanal der Distribution-Sicherheitsteams) informiert
  • Auch im Fall von CopyFail gab es keine Vorwarnung (Heads-up) über die linux-distros-ML
  • Das bedeutet, dass die Sicherheitsteams wichtiger Distributionen wie Ubuntu, RHEL und SUSE vor der Offenlegung der Schwachstelle keine Gelegenheit hatten, Patches vorzubereiten

[unsure4000]

Der Blogbeitrag wirkt zwar etwas kindisch, aber ich denke, dass die systemischen Mängel größer sind, als es als bloßes Ärgernis abzutun.

[GN⁺]

Hacker-News-Kommentare

• Sam James, der Autor des verlinkten Beitrags, ist Gentoo-Entwickler
  Wie auch immer: Das kommt fast einer Katastrophe gleich, und es war äußerst unverantwortlich, den Exploit offenzulegen, bevor die Distributionen einen Fix ausliefern konnten
  Man weiß nicht, wie viele Shared-Hosting-Anbieter dadurch kompromittiert wurden
  Besorgniserregend ist auch, dass es offenbar keine Kommunikation zwischen dem kernel security team und den Distribution-Maintainern gibt
  Man würde erwarten, dass Ersteres Letztere informiert, aber in der Praxis scheint die Verantwortung bei der Person zu liegen, die die Schwachstelle gefunden hat

  • Ich sehe kein Problem darin, die Sache 30 Tage nach Einspielen des Patches bei den Empfängern offenzulegen
    Zur Einordnung: Google Project Zero nutzt ähnlich die „90+30“-Policy: https://projectzero.google/vulnerability-disclosure-policy.h...
    Das eigentliche Problem ist, dass es keinen Kommunikationskanal zwischen dem kernel security team und den Distribution-Maintainern gibt
    Die Person, die die Schwachstelle entdeckt, sollte nicht dafür verantwortlich sein, jeden Downstream einzeln zu informieren
    Das Kernel-Team hätte die Liste der Distributions-Sicherheitsverantwortlichen über die Kritikalität des Patches und den Offenlegungstermin in 30 Tagen informieren müssen
  • Diese Offenlegung wirkte eher wie Marketing als wie Sicherheit
    Auf der Veröffentlichungsseite stehen Formulierungen wie „Is your software AI-era safe?“, „Copy Fail was surfaced by Xint Code about an hour of scan time against the Linux crypto/ subsystem“, „[Try Xint Code]“
    Das ist eine Art, das Produkt attraktiver wirken zu lassen, je größer die Verwirrung wird
  • Als Nutzer und Administrator stimme ich „äußerst unverantwortlich“ nicht zu
    Der Ausdruck Responsible Disclosure ist wie „Secure Boot“ sprachlich sehr geschickt konstruiert und wirkt in der Praxis eher wie Reputationsmanagement für die Unternehmen und Stiftungen zwischen mir und meinem Computer
    Diese Organisationen interessieren sich weniger dafür, ob mein einzelner Rechner verwundbar ist, sondern eher dafür, dass niemand sagen kann „RHEL ist verwundbar“ oder „Ubuntu ist verwundbar“
    Die Schwachstelle existiert ohnehin, also ist es besser, das Risiko zu kennen und mindern zu können, als einfach nur auf einen stillen Fix zu warten
    Ich halte eine sofortige Offenlegung für die einzige nicht unverantwortliche Wahl
  • Unabhängig von der Position zum Offenlegungsprozess: Wenn ein Hosting-Provider dadurch kompromittiert wurde, war seine Architektur ohnehin zum Verlieren verurteilt
    Sich gegenseitig nicht vertrauende Tenant-Workloads unter einem einzigen Shared Kernel laufen zu lassen, ist keine gute Idee
    Kernel-LPEs sind nicht selten, dieser hier war nur besonders simpel und portabel, und die primitive Capability selbst kommt beinahe einer Commodity im CNE-Bereich gleich
  • Der Linux kernel eignet sich nicht als Sicherheitsgrenze
    Wer Shared Hosting betreibt und nicht kompromittiert werden will, sollte andere Mittel wie gVisor oder Firecracker-VMs verwenden
    Das wichtigste System, das ihn als Sicherheitsgrenze nutzt, ist wohl Android, dort wird das aber durch Benutzerbestätigung bei APK-Installationen, strikte SELinux- und seccomp-Policies sowie GrapheneOS-Hardening abgeschwächt
    Auch in diesem Fall hat die Minderung funktioniert: https://discuss.grapheneos.org/d/35110-grapheneos-is-protect...

• Ich verstehe nicht, warum man sagt, bei Linux-kernel-Schwachstellen gebe es für Distributionen keine Vorabinformation, es sei denn, der Reporter bringe sie selbst zur linux-distros-ML
  Das setzt voraus, dass der Reporter ein hohes Maß an Wissen über das Linux-Projekt und seine Abläufe hat
  Ein Meldender sollte nicht dafür verantwortlich sein, direkt mit allen Downstream-Konsumenten des Linux-Kernels zu arbeiten
  Nach derselben Logik müsste man dann auch jeden Hersteller direkt kontaktieren, der Linux in Geräten verwendet
  Ich finde, der Meldende hat seine Pflicht bereits erfüllt, indem er das Problem verantwortungsvoll an Linux gemeldet und gewartet hat, bis ein Patch vorlag
  Innerhalb des Linux-Projekts sollte es Personen mit Zuständigkeit und Verantwortung für Sicherheitslücken geben, und sie sollten auch die Downstream-Distributionen informieren

  • Das gilt umso mehr, als Reporter ausdrücklich gebeten werden, nicht zuerst die Distributionsteams zu informieren
    https://docs.kernel.org/process/security-bugs.html
    As such, the kernel security team strongly recommends that as a reporter of a potential security issue you DO NOT contact the “linux-distros” mailing list UNTIL a fix is accepted by the affected code’s maintainers and you have read the distros wiki page above and you fully understand the requirements that contacting “linux-distros” will impose on you and the kernel community.
  • Der Reporter hatte Zeit, auf seiner Website bestimmte Distributionen wie Ubuntu/RHEL/SUSE zu prüfen und zu nennen
    Da wäre es zumindest verantwortungsvoll gewesen, die Sicherheitsteams dieser Distributionen zu informieren
  • Es ist schwer nachzuvollziehen, warum es vernünftig sein soll, dass der Reporter eine Website erstellt, die Ubuntu, RedHat, Amazon und SUSE ausdrücklich nennt, sie aber nicht informiert
    Dass diese Distributionen Downstream des Kernel-Teams sind, kann ihm kaum unbekannt gewesen sein
  • Vielleicht war es keine harte Pflicht, aber ich denke, alle leiden jetzt mehr, weil den Reportern sichere remediation weniger wichtig war als Aufmerksamkeit
  • Es ist sehr einfach herauszufinden, wie man solche Sicherheitsprobleme an Linux-Distributionen meldet
    Eine Google-Suche reicht: https://share.google/aimode/eihDKXZJy94Z5lC1p
    Ohne darüber nachzudenken alle einem Exploit auszusetzen, ist schwer nachvollziehbar und in manchen Rechtsräumen womöglich nicht einmal weit von einem schweren Delikt entfernt

• Der interessanteste Austausch zur disclosure steht unter diesem Link
  https://www.openwall.com/lists/oss-security/2026/05/01/3
  Das ist die Antwort von greg k-h: „Wir können niemanden vorab informieren, denn dann müssten wir alle über alles informieren. Das ist die einzige Policy, der Rechts- und Regierungsstellen zugestimmt haben, unter der wir operieren dürfen.“

  • Ich mag Linux, aber das halte ich für eine dumme Policy

• Statt die Reporter verantwortlich zu machen, sollte man fordern, den Kernel-Prozess zu ändern
  Der Linux-Kernel ist längst kein Spielzeugprojekt mehr, dort arbeiten Vollzeitbeschäftigte aus vielen Unternehmen
  Die Benachrichtigung der Distributionen hätte von ihnen übernommen werden müssen, nicht von irgendeiner Einzelperson

  • Wenn man in einem ankündigenden, faktisch marketinggetriebenen Blogpost bestimmte Distributionen namentlich als betroffen aufführt, dann ist ein vorheriger Heads-up angemessen und zu erwarten
    Hätte man Hinweise wie auf RHEL 14 nicht so eingebaut, wäre die Kritik vermutlich weit geringer ausgefallen
    Hier geht es nicht um einen unabhängigen Sicherheitsforscher oder die Wissenschaft, sondern um ein Sicherheitsunternehmen mit professioneller Kommunikationsabteilung, das mit dem Finger auf Distribution-Maintainer zeigt
  • Natürlich sollten Distributionen und Kernel-Entwickler bei Patches mit hoher Schwere kommunizieren und schnell handeln
    Aber weil der Reporter nicht darauf gewartet hat, dass das geschieht, könnten reale Menschen Schaden erlitten haben, und dafür trägt der Reporter Verantwortung
  • Eine Schwachstelle zu melden und einen starken Exploit zu veröffentlichen, den jeder sofort verwenden kann, sind zwei völlig verschiedene Dinge
    Das ohne vorherige Information der großen Distributionen in die Welt zu setzen, war unverantwortlich

• Für Leute, die einen Kernel nutzen, bei dem AF_ALG nicht als Modul, sondern direkt in den Kernel gelinkt ist, wurde ein eBPF-basierter Workaround veröffentlicht: https://github.com/Dabbleam/CVE-2026-31431-mitigation
  Er läuft derzeit in Production, mindert die Angriffe und bislang sind keine unerwarteten Nebenwirkungen zu sehen

• Ich denke, nosuid und wahrscheinlich auch nodev sollten Standard-Mount-Optionen für Dateisysteme sein
  /dev ist bereits eine spezielle devtmpfs, und das minimale /dev des initrd kann bei Bedarf dadurch bereitgestellt werden, dass man die initrd-tmpfs-rootfs explizit mit dev und suid mountet
  Zu erlauben, dass SUID-Binaries irgendwo einfach „existieren“ können, ist ein großes Sicherheitsrisiko
  Wie soll man beim Mounten externer Speichermedien verifizieren, ob die SUID-Binaries auf diesem Block-Device bösartig sind?
  Außerdem scheint dieser Exploit nur zu funktionieren, wenn der Benutzer, der das SUID-Binary ausführt, das Binary auch lesen kann
  Es gibt keinen guten Grund, warum Nicht-Root-Benutzer Leserechte auf SUID-Binaries haben sollten
  NixOS macht das richtig
  Im normalen Paketinstallationsverzeichnis /nix/store gibt es kein SUID, und weil Pakete nicht daraus herauslecken, kann man auf anderen Mountpoints gefahrlos nosuid verwenden
  Die einzige Ausnahme ist das Einzweckverzeichnis /run/wrappers.$hash, das nur executable-only-SUID-Wrapper sicher enthält

  • Ich mag suid auch nicht, aber suid ist hier nicht das eigentliche Problem
    Der ausgenutzte Bug ermöglicht faktisch beliebige Page-Cache-Poisoning-Angriffe
    An diesem Punkt ist das Spiel ohnehin vorbei, und ein suid-Programm zu patchen ist vielleicht der einfachste Weg zur Root-Shell, aber nicht der einzige
  • Der Proof-of-Concept-Exploit soll wörtlich nur einen Angriffsvektor demonstrieren
    Es gibt viele andere Wege
    Wenn das Ziel nur wäre, den PoC-Exploit zu blockieren, gäbe es einfachere Methoden wie Blacklists, aber das würde die Lage nicht sicherer machen
    Mit dieser Schwachstelle kann man den page cache manipulieren
    Man kann ld.so manipulieren, um beliebige Systemaufrufe zu hooken, die uid auf 0 zu setzen oder auf viele andere Arten eine Rechteausweitung zu erreichen
    Mountpoints haben mit diesem Problem nichts zu tun
    Natürlich ist es immer sinnvoll, suid in benutzerschreibbaren Bereichen zu verbieten und das Lesen von suid-Dateien zu unterbinden, aber aus anderen Gründen
    Auch NixOS behebt diese Schwachstelle nicht und ist genauso verwundbar wie andere Distributionen
  • Ohne Leserechte kann man ein Binary nicht ausführen, und das ist auch logisch
    Um ein Binary auszuführen, muss es von der Platte gelesen und in den Speicher geladen werden
    Tatsächlich kann man, wenn man auf ein bestimmtes Binary Leserechte, aber keine Ausführungsrechte hat, den Linker direkt aufrufen, um es auszuführen
    Zum Beispiel mit /bin/ld.so.1 /path/to/binary; dann liest und lädt der Linker das Binary und springt anschließend ohne exec()-Aufruf zum Entry Point

• Unter dem folgenden Bleeping Computer-Link stehen mögliche Gegenmaßnahmen, bis Patches bereitstehen
  https://www.bleepingcomputer.com/news/security/new-linux-cop...

  • Dieser Workaround gilt nur für Kernel, bei denen der betroffene Code als Modul kompiliert wurde
    RHEL, Fedora und Gentoo sind alle so konfiguriert, dass dieser Code direkt in den Kernel gebaut wird
    Ohne Patch oder Konfigurationsänderung bleiben diese Distributionen also weiter verwundbar, wie Sam für Gentoo andeutete
  • Bei RedHat und seinen abgeleiteten Distributionen ist der betroffene Code nicht als Modul, sondern statisch kompiliert, daher funktioniert diese Gegenmaßnahme dort nicht

• NixOS wurde ebenfalls nicht vorab informiert
  https://discourse.nixos.org/t/is-nixos-affected-by-copy-fail...

  • Keine Distribution wurde vorab informiert

• Hyperbola GNU war sicher, weil es aus politischen Gründen und zugunsten der Stabilität noch Python 3.8 nutzt

• Ubuntu hat einen Patch veröffentlicht, und Tests vor und nach dem Patch wurden abgeschlossen