Die entsprechenden Copy-Fail-Statusseiten bei Ubuntu (Blogbeitrag, CVE-Datenbankeintrag) sind derzeit übrigens nur via Wayback-Machine einsehbar: Blogbeitrag, CVE-Dantenbankeintrag…
EDIT: Laut https://status.canonical.com/ dauert der Ausfall mittlerweile 13,5 Stunden an; angeblich hat zwischenzeitlich eine irakische Aktivistengruppe behauptet, hinter einem DDOS-Angriff der Infrastruktur zu stecken.
Ich kann nicht mal die Statusseite öffnen. Mir fehlen die Berechtigungen dafür 
Ich kann nicht mal die Statusseite öffnen. Mir fehlen die Berechtigungen dafür
Oh. Aber da ist auch nichts Schönes zu sehen (EDIT1: laut Vorfallsdetailansicht sind es inzwischen 14,5 Stunden Ausfallszeit).
EDIT2: Heureka!
small (apparently american english) nitpick: it should be "doesn't currently offer" since Netcup as a company name is singular. 
Das Modul zu blockieren hilft nur auf den Debian-Systemen, die Red Hat, Alma und Rocky-Systeme haben kein Modul, sondern alles fest eingebaut.
Wenn
Code# rmmod algif_aead rmmod: ERROR: Module algif_aead is builtin.erscheint, dann hilft der Module disable workaround nicht, aber er schadet auch nicht.
Hab den Fix per Kernel soeben umgesetzt, ich hatte aber vorher geprüft ob der CVE bei mir "offen" gewesen wäre.
Unter Alma mit korrektem SE Kontext wird der Zugriff ohnehin verweigert, aber sicher ist sicher daher den Patch gesetzt.
Habt ihr alle schon brav (Kernel) Updates gemacht und neugestartet, heute am Tag der Arbeit? :>
https://www.heise.de/news/Copy-Fail-Linux-root-in-allen-grossen-Distributionen-mit-732-Byte-Python-11277590.html
Habt ihr alle schon
YOLO.
Habt ihr alle schon brav (Kernel) Updates gemacht und neugestartet, heute am Tag der Arbeit? :>
https://www.heise.de/news/Copy-Fail…n-11277590.html
ja, gestern gegen 23 Uhr.
small nitpick: it should be "doesn't currently offer" since Netcup as a company name is singular.
Your mileage may vary, but I'm siding with the British* on this one … 
(*more precisely, those who are at least as old as me)
Habt ihr alle schon brav (Kernel) Updates gemacht und neugestartet, heute am Tag der Arbeit?
https://wiki.debian.org/PeriodicUpdates?action=show&redirect=UnattendedUpgrades
Ja. Automatisch. Heue nacht.
bloss, ohne einen Reboot wird das wohl eher nicht aktiviert, auch wenn es installiert ist
bloss, ohne einen Reboot wird das wohl eher nicht aktiviert, auch wenn es installiert ist
Die Server machen auch automatische Reboots, wenn nötig. Alles läuft über Docker, daher ist alles nach Neustart automatisch wieder da.
dann ist ja alles gut
bei meinen Servern werden zwar all Updates eingespielt, aber nix automatisch rebootet, dies nur nach Ankündigung ....
...es empfiehlt sich aber vor dem `rmmod` zu prüfen ob, das Modul derzeit bereits geladen ist, und falls ja, festzustellen ob dies durch eine legitime Anwendung oder ggf. bereits maliziös passiert ist...
Hmm... wenn ich unter Debian mittels
lsmod | grep algif_aead
nachschaue, sehe ich zumindest ob das Modul aktuell geladen ist, oder?
Das bringt (abgesehen von einem Kernel Update) natürlich erstmal keine wesentliche Erkenntnis, denn das Modul hätte gestern Nachmittag geladen sein können & ausgenutzt worden sein & der VPS kompromittiert worden sein & das Modul mit rmmod durch den Angreifer entfernt worden sein.
Codesudo tee /etc/modprobe.d/disable-algif-aead.conf <<<'install algif_aead /bin/false' sudo rmmod algif_aead 2>/dev/null
Danke, das ist ja auch ohne Kernel-Update unter Debian ratz fatz erledigt & wieder was gelernt
Tolle Sache, da ist wohl so einiges übelst verbockt worden. Wer hat sich denn sowas ausgedacht?
Linux ist total sicher, das ist OpenSource, da gucken lauter Profis drauf
If your kernel was built between 2017 and the patch (April 2026) — which covers essentially every mainstream Linux distribution — you're in scope.
Bin mir jetzt nicht so sicher ob staatliche Akteure (weltweit) diesen Angriffsvektor nicht schon früher gefunden und genutzt haben. Knapp 10 Jahre eine 'so einfach' nutzbare Möglichkeit für root...
Da hilft dann nur den Server komplett neu aufzusetzen, denn ein früher bereits kompromittierter Server (z.B. irgendwelche Hintertüren eingebaut) ist ja auch nach einem Kernel-Update bzw. Patch noch immer kompromittiert.
Codesudo tee /etc/modprobe.d/disable-algif-aead.conf <<<'install algif_aead /bin/false' sudo rmmod algif_aead 2>/dev/null
man könnte noch
sudo tee /proc/sys/vm/drop_caches <<<'echo 3'hinterherwerfen, um die caches zu leeren, falls man vorher den exploit ausprobiert hat und muss damit auch nicht rebooten.
Oh je, es artet in Stress aus:
Wobei aktuell Debian für Raspi noch hinterher hinkt. Noch kein neuer Kernel zur Verfügung
Wobei aktuell Debian für Raspi noch hinterher hinkt. Noch kein neuer Kernel zur Verfügung
Das stimmt. Aber der Workaround mit dem geblockten Modul hilft auch auf den Raspis.
Bei mir verteilt Ansible die Modulkonfiguration auf alle Rechner, inklusive der Raspis. Und es baut bei Aenderungen auch die Initrd neu. Also einmal zentral eine Datei aendern, den Rest macht Ansible. Ohne so eine Automatisierung moechte ich meinen Rechnerzoo nicht mehr administrieren.
Bei Reboots beisst mich dann allerdings die Vollverschluesselung, die ich auf vielen Systemen habe. Da muss ich dann von Hand ran.
Der neue Kernel hat uebrigens noch einen Haufen weiterer Fixes. Der sollte also trotz Workaround zuegig aktiviert werden.
Ich glaube der Inhaberwechsel hat heute auch 1.Mai und frei, oder ist am booten wegen den Kernel patches. Denn ich warte nun schon seit 13:30 und das steht immer noch "Der Inhaberwechsel wird bearbeitet. Nach dem erfolgreichen Abschluss übernehmen Sie die Verträge der unten aufgeführten Produkte."
Schauen wir mal was der Support meint.
Das stimmt. Aber der Workaround mit dem geblockten Modul hilft auch auf den Raspis.
Das Habe ich auf meinen 4 Raspi ausgeführt. Somit sind die Sicher bis der neue Kernel zur Verfügung steht.
Linux ist total sicher, das ist OpenSource, da gucken lauter Profis drauf
Der kommt freitags immer gut im Heise Forum. 
Somit sind die Sicher bis der neue Kernel zur Verfügung steht.
Meinst Du den 2027 Kernel der den root exploit von 2018 fixt?
