Status
Es gibt diese Tage, an denen bei System Engineers die rote Lampe angeht. Der 30. April 2026 war so ein Tag.
Um 8:29 Uhr wird im internen Slack ein Artikel zu einem 0-Day-Exploit im Linux-Kernel geteilt, öffentlich publiziert auf cybersecuritynews.com. CVE-2026-31431, getauft auf den Namen «Copy Fail». Eine lokale Rechte-Erweiterung im Linux-Kernel, durch eine Code-Anpassung im Linux in Version 4.14 im Jahr 2017 hinzugefügt. Und – das Sahnehäubchen – ein funktionierender Exploit steht auf GitHub bereit. Ein paar Zeilen Python, und ein beliebiger unprivilegierter User wird zu root:
www-data@test-noble03:~ $ python3 copy_fail_exp.py
# id
uid=0(root) gid=33(www-data) groups=33(www-data),4(adm),112(ssl-cert)
So einfach. So schnell. Auf einem aktuellen Ubuntu Noble (24.04). Und für unsere Ubuntu-Flotte war zu diesem Zeitpunkt noch kein neuerer Kernel verfügbar.
Warum das ein Problem ist
Auf einem klassischen Webserver laufen Applikationen im Kontext eines unprivilegierten Benutzers, typischerweise www-data. Das ist verbreitete «best practice»: Selbst wenn ein Angreifer es schaffen sollte, eine Schwachstelle in PHP, Node.js oder Ruby auszunutzen, gelangt er nur an die Rechte dieses Benutzers. Unix-Dateirechte halten ihn dann von den Daten anderer Kunden und von Root-Secrets fern – vorausgesetzt, diese Rechte sind korrekt gesetzt. Die Auswirkung bleibt eingegrenzt.
Eine lokale Rechte-Erweiterung überbrückt diese Grenze. Aus «kompromittierte Webapp» wird «kompromittierter Server». Der Kernel ist die letzte Verteidigungslinie, Applikationssicherheit die erste und wir müssen Vorkehrungen treffen und diese letzte Linie mit den verfügbaren Mitteln absichern. Insbesondere dann, wenn ein funktionierender Exploit bereits öffentlich und trivial ausführbar ist.
Unser Engineering-Team hat verifiziert, dass der Exploit nicht nur auf virtuellen Maschinen oder dedizierten Servern funktioniert, sondern auch in einer Container-Umgebung. Das bedeutete in diesem Moment, dass auch unsere Kubernetes-Umgebung möglicherweise exponiert ist. Ein Kernel-Bug, der einem unprivilegierten Prozess Root-Rechte gibt, hebelt die Isolation einer geteilten Plattform wie Deploio aus: genau das Szenario, das es unter allen Umständen zu vermeiden gilt.
Mitigation statt abwarten
Probleme dieser Grössenordnung verlangen sofortige Aufmerksamkeit und Gegenmassnahmen. Solange noch kein Patch verfügbar ist, muss schnellstmöglich eine Mitigation implementiert werden. Die Schwachstelle ist ein Out-of-Bounds-Write im Kernel-Modul algif_aead und nur über die AF_ALG-Socket-Schnittstelle der Crypto-User-API erreichbar. Modul entladen, das Nachladen verhindern, und der Angriffsvektor ist mitigiert.
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead 2>/dev/null
Die Mitigation wurde in unserer internen Kommunikation geteilt, zuerst getestet, dann in unsere Automatisierung integriert und auf alle unsere Managed Server ausgerollt. Nach dem Rollout haben wir die Mitigation auf mehreren Maschinen erneut verifiziert, um sicherzustellen, dass sie wie beabsichtigt funktioniert. Die Rechte-Erweiterung liess sich nicht mehr reproduzieren.
Von der ersten Slack-Nachricht bis zum bestätigt sicheren Stand der Flotte: rund eine Stunde.
Und Kubernetes?
Unsere Kubernetes-Plattform NKE und Deploio laufen nicht auf Ubuntu, sondern verwenden Flatcar Container Linux. Ein Engineer hat sich die Kernel-Konfiguration der bei uns laufenden Versionen angeschaut, auf Staging und Production. Resultat: algif_aead wird in der Standardkonfiguration von Flatcar nicht als Modul mitgeliefert. Nur algif_hash und algif_skcipher sind präsent.
Heisst: Der Angriffsvektor über das Kernel-Modul algif_aead existiert auf unseren Kubernetes- und Deploio-Umgebungen schlicht nicht. Die Flatcar-Entwickler hatten CONFIG_CRYPTO_USER_API_AEAD deaktiviert, und wir haben zufällig davon profitiert. Flatcar selbst hat bestätigt, dass sie von dieser Sicherheitslücke nicht betroffen sind.
Wir behalten die Flatcar-Release-Notes natürlich trotzdem im Auge, für den Fall der Fälle. An diesem Morgen konnten wir an der Stelle einmal kurz durchatmen.
Was ich aus heute mitnehme
Mitigationen verschaffen Zeit. Solange noch kein Patch verfügbar ist, kann das zielgerichtete Entfernen des Angriffsvektors – hier: algif_aead entladen und das Nachladen blockieren – die Zeit überbrücken, bis ein Patch zur Verfügung steht. Kein Ersatz für das eigentliche Patchen, aber der Unterschied zwischen «für Stunden exponiert» und «für Tage exponiert» ist erheblich.
Ein gutes Team ist alles. Rund ein halbes Dutzend Engineers war in der Slack-Unterhaltung aktiv und die Diskussion war ein Beispiel aus dem Lehrbuch: Jemand findet das Problem, jemand verifiziert den Exploit, jemand recherchiert die Mitigation, jemand rollt sie aus, jemand prüft die Flotte, jemand testet die Wirksamkeit. Keine Eskalation und kein Drama, nur zielgerichtetes Engineering, bei dem eine Hand in die andere greift. Chapeau an alle Beteiligten.
Wer bei uns einen Root Server betreibt, ist selbst am Steuer: Das ist der Deal. Falls du dazugehörst: Die oben gezeigte Mitigation (install algif_aead /bin/false plus rmmod) lässt sich in einer Minute umsetzen, kein Reboot nötig. Sobald die Distribution den Kernel-Patch ausliefert, einfach updaten und neu booten.
Wenn du dich fragst, was hinter dem Wort «Managed» bei Managed Server eigentlich passiert: Das hier war ein ganz normaler Donnerstagvormittag.
