Die derzeit stattfindende Killswitch-Diskussion dreht sich um einen Notfall-Mechanismus im Linux-Kernel, mit dem ein privilegierter Admin einzelne verwundbare Kernel-Funktionen zur Laufzeit abschalten kann, statt auf einen vollständigen Fix zu warten. Die Idee dahinter ist nicht, den Bug zu reparieren, sondern den gefährlichen Codepfad vorübergehend unzugänglich zu machen. Der Switch soll lediglich das Zeitfenster zwischen Schwachstellen-Offenlegung und verfügbarem Patch überbrücken.
Vorschlag von Sasha Levin
Der Vorschlag stammt von Sasha Levin, einem prominenten, bei NVIDIA beschäftigten Co-Maintainer der stabilen und Long-Term-Support-Kernel-Zweige. Er hat einen Patch vorgeschlagen, der einen Mechanismus namens Killswitch in den Linux-Kernel einführt. Er soll privilegierten Systemadministratoren ermöglichen, eine verwundbare Kernel-Funktion auf einem laufenden System zu deaktivieren. Das könnte über das virtuelle Dateisystem securityfs umgesetzt werden. Der Effekt tritt sofort auf allen CPU-Kernen in Kraft und bleibt aktiv, bis der Admin ihn deaktiviert oder das System neu startet. Es gibt auch eine Boot-Parameter-Variante, um die Maßnahme über einen Bootloader auf ganzen Flotten auszurollen.
Zu früh offengelegt
Auslöser waren die in jüngster Vergangenheit aufgetauchten hochkritischen Kernel-Schwachstellen Copy Fail und Dirty Frag, die beide veröffentlicht wurden, bevor die Distributionen Zeit hatten, gepatchte Kernel zu erstellen, zu testen und zu veröffentlichen. Für solche Fälle argumentieren Killswitch-Befürworter, es sei besser, kurzfristig eine Funktion abzuschalten, als ein bekannt verwundbares System weiterlaufen zu lassen.
Zu großer Hammer
Aber natürlich gibt es auch Kritik an einem solchen tiefen Eingriff. Der Hauptkritikpunkt lautet, das skizzierte Vorgehen sei ein viel zu großer Hammer. Wenn man die falsche Funktion abschaltet, kann das ganze Subsystem oder sogar das Systemverhalten unerwartet verändert werden. Außerdem könnten Nutzer bestehende Abhängigkeiten verlieren. In den Diskussionen wird auch gefragt, ob man mit so einem Mechanismus nicht zusätzliche Angriffs- oder Missbrauchsmöglichkeiten schafft, gerade weil Root damit gezielt Kernel-Verhalten verändern kann.
Für und Wider
Red Hat-Vizepräsident Mike McGrath als Befürworter des Killswitches erklärte, man unterstütze die Integration von Killswitch-Fähigkeiten in den Kernel, insbesondere da das Tempo und die Schwere von Exploits durch LLM-gestütztes Scanning zunehmen. Patches seien absolut notwendig, aber auch häufig disruptiv – nicht-disruptive Mitigationen seien für den Moment-Schutz entscheidend.
Auf Reddit wurde der Vorschlag in der r/cybersecurity-Community als riskante Idee bezeichnet, denn der Killswitch sei möglicherweise »eine Sicherheitsfunktion, die schlimmer sein könnte als die Schwachstelle selbst«. Hinzu kommt: Wenige Admins können auf Anhieb einschätzen, welche Auswirkungen das Deaktivieren einer Kernel-Funktion auf ihre Dienste hat. Das müsste getestet und validiert werden, was Zeit und Aufwand kostet.
Der Patch befindet sich derzeit noch in der Überprüfung und wurde noch nicht in den Linux-Kernel aufgenommen. Ob und in welcher Form er dort landet, wird sich im nächsten Review-Zyklus zeigen.
Muß es denn der Admin sein? Es könnte doch der Distributor sein, quasi Aktivierung des kill switches durch ein Update bis das echte Update kommt.
Wenn man doch weiss, wie eine Schwachstelle zu entschärfen ist, dann kann man doch eigene Kernel bauen und ausrollen, also z.B. in hart sicherheitsrelevanten Bereichen, wo sicher auch Admins arbeiten, die die Auswirkungen abschätzen können.
Aber eine neue grundsätzliche Funktion generell einbauen, die das kann? Das schafft ja wieder neue Angriffsvektoren. Ja, man könnte Kernel-Funktionen onthefly ohne Neustart deaktivieren im Gegensatz zum Neukompilieren und Einspielen eines Kernels inkl. Neustart. Aber da dreht sich das wieder im Kreis. Kann man einschätzen, welche Auswirkungen das hat, ohne entsprechende Tests?
Es geht doch hierbei nur um eine Funktionsabschaltung zur Mitigation für den Zeitraum zwischen der nicht abgesprochenen Veröffentlichung einer Lücke oder gar eines Exploits und einem einsatzbereiten Fix. Auch wenn ein Fix erstellt wurde, geht der ja nicht ohne weitere QA raus. Und wenn er in Mainline angekommen ist, müssen ja auch noch die Distributionskernel gebaut und getestet werden. Wie groß das Risiko eines solchen Schalters ist, vermag ich nicht einzuschätzen.