Technische Unterstützung
Dokumentation
Anmeldung
Kontakt
Neue Linux-Kernel-Funktionalität bedeutet neue Angriffsfläche
Joao Correia
29. Dezember 2022. TuxCare-Expertenteam
Der Linux-Kernel hat im Laufe der Jahre an Umfang und Funktionalität gewonnen. Neue Scheduler, neue Treiber, neue Dateisysteme, neue Kommunikationsprotokolle, neue Sicherheitslücken... oh, Moment. Das letzte ist nicht wie die anderen. Tatsächlich sind neue Sicherheitslücken oft das Ergebnis neu hinzugefügter Funktionen. Sicher, nicht jede neue Funktion bringt neue Sicherheitslücken mit sich - aber die, die es tun, sprechen für eine massive Codebasis, die anfällig für unerwartete, obskure und verschleierte Interaktionen ist, die zu gefährlichen Situationen führen.
Wie wird die Funktionalität hinzugefügt?
Jedes einzelne Kernel-Subsystem war irgendwann einmal für jemanden so nützlich, dass es zur Aufnahme in die Kernel-Hauptcodebasis eingereicht wurde. Die meisten, wenn nicht sogar alle, dieser Subsysteme könnten wahrscheinlich eher im Userspace als direkt im Kernel implementiert werden, aber das ultimative Ziel eines Einreichers von solchem Code ist es, jedes mögliche Quäntchen an Leistung zu gewinnen. Direkt im Kernel-Ausführungsbereich zu sein bedeutet, dass es weniger Kontextwechsel gibt, direkten Zugriff auf Speicherbereiche, die sonst unerreichbar wären, und allgemein einfachere und schnellere Aufrufe zu anderen Kernfunktionen und Hardwarezugriff.
Im Laufe der Jahre führte dies zu einer starken Zunahme der Unterstützung von Dateisystemen (es gibt jetzt Dutzende verschiedener Dateisysteme, die direkt vom Kernel unterstützt werden), NTFS, exFAT, XFS und vielen, vielen anderen - und sie alle haben einen zwingenden Grund, Teil des Kernels zu sein. Das Gleiche gilt für Paketfiltermodule, Netzwerkprotokolle - alles, was dazugehört. Es gibt unzählige andere, die für eine zukünftige Aufnahme in den Kernel eingereicht, geprüft und umgeschrieben werden (ZFS, jemand?). Wie viele Dateisysteme braucht man wirklich auf einem bestimmten System?
Das Gleiche gilt für die Fehlersuche, da es mehrere Funktionen zur Fehlersuche innerhalb des Kernels gibt. Manchmal konkurrieren sie sogar miteinander und können nicht gleichzeitig aktiviert werden.
Es ist ähnlich wie hier:
Und wo ist der Haken?
Als der Linux-Kernel ins Leben gerufen wurde, war das Internet ein Staubkorn im Vergleich zu dem, was es heute ist. Die Zahl der vernetzten Systeme und sogar die Gesamtzahl der Netze auf der ganzen Welt konnte relativ leicht gezählt und aufgelistet werden. Wahrscheinlich kannten Sie die Betreiber der Systeme, mit denen Sie regelmäßig verbunden waren, beim Namen. Cybersicherheit war damals noch kein Thema.
Das Hinzufügen neuer Funktionen zum Kernel verschaffte dem Projekt also einen breiteren Rahmen und eine größere Reichweite für ein großartiges Stück Software und ermöglichte auch eine große Erweiterung der Benutzerbasis - die sich zu einer Kerngruppe von Linux-Enthusiasten verdichtete, die das Projekt leitete, als es eine ausreichende Größe erreichte.
Es gab nicht viele Gründe, etwas Neues und Interessantes für jemanden nicht aufzunehmen. Das Gegenteil war der Fall - mehr Funktionen bedeuteten mehr interessierte Nutzer.
Die Dinge haben sich geändert. Ziemlich viel sogar.
Lassen Sie Ihr Gepäck an der Tür
Wie sich herausstellt, führt das Hinzufügen vieler komplexer Codeteile zu etwas, das durch Zuwachs wächst, manchmal zu unerwarteten Ergebnissen.
Nehmen wir das Berkley Packet Filter (BPF) Subsystem als Beispiel. Ursprünglich konzipiert und vorgeschlagen als eine Möglichkeit, neue, maßgeschneiderte Firewall-Implementierungen hinzuzufügen, ermöglicht es den Benutzern, praktisch jeden beliebigen Code hinzuzufügen und ihn im Ausführungskontext des Linux-Kernels auszuführen. Außerdem war es in den letzten Jahren die Quelle für Dutzende von Sicherheitslücken, von denen einige ziemlich schwerwiegend waren. In Anbetracht seines Zwecks ist dies nicht völlig unerwartet.
Bei anderen sind die Risiken, die sie mit sich bringen, nicht so eindeutig.
Betrachten wir ein anderes Beispiel. Letztes Jahr wurde das Subsystem ksmbd vorgeschlagen und in den Kernel aufgenommen. Es ähnelt in gewisser Weise Samba (d.h. es ermöglicht die Nutzung der SMB-Dateifreigabe direkt, anstatt sich auf eine separate Software zu verlassen). Letztendlich sollte es schnellere SMB-Übertragungsgeschwindigkeiten ermöglichen, indem es sich auf kürzere Call-Stack-Tiefen stützt (indem es Kernel-Funktionen direkt aufruft und nicht wie Samba über die Kernel-ABI). Wenn man die Geschichte von SMB mit Schwachstellen, Würmern, Exploits und anderen üblen Geschichten kennt, könnte man sich Sorgen machen, aber es ging in den Kernel, gesponsert von Samsung. Wie es um die Cybersicherheit bestellt ist, wurde vor ein paar Tagen öffentlich bekannt gegeben, dass eine 10 (von 10) Risikoschwachstelle in ksmbd bestehteine Sicherheitslücke mit einem Risiko von 10 (von 10) aufweist, wie sie in der Codebasis von Kernel 5.15 (z. B. Ubuntu 22.04) vorhanden ist.
Wir fügen nicht einfach nur neue Funktionen hinzu. Wir fügen auch all die Fehler und unerwarteten Wechselwirkungen zwischen neuem und altem Code hinzu, die leider nur in Produktionssystemen offensichtlich sind.
Ein (weiterer) Klumpen Kohle zu Weihnachten
Genau wie bei der berüchtigten Log4j-Schwachstelle im letzten Jahr ist die Weihnachtszeit ein fruchtbarer Boden für die Ausbreitung sehr gefährlicher Sicherheitslücken. Genau wie Sysadmins und Sicherheitsteams damit zu kämpfen hatten, Log4j in den Griff zu bekommen und rechtzeitig zu patchen, ist diese neue ksmbd-Schwachstelle eine weitere "Patch-now-or-you'll-be-hacked"-Schwachstelle. Sie ist aus der Ferne ausnutzbar, leicht auszulösen und ermöglicht vollen Systemzugriff. Bisher muss sich ein Benutzer anscheinend für eine Freigabe authentifizieren, um die Schwachstelle auszulösen - das ist zwar eine gute Nachricht, aber immer noch eine ziemlich ernste. "Jetzt patchen" ist eine Untertreibung.
Und was ist mit den neuen Sicherheitslücken, die auftauchen, wenn die IT-Teams nur mit einer Notbesetzung arbeiten und langsamer reagieren? Oh, warte...
Überlegungen zur Ursachenforschung
Dies ist keine Kritik an bestimmten Subsystemen. Es ist nicht einmal eine Kritik am Kernel selbst oder an seinem Entwicklungsprozess - sein unbestreitbarer Erfolg ist offensichtlich. Aber, und es gibt immer ein "aber", vielleicht sollten neue Subsysteme länger in der Testphase bleiben. Oder, wenn eine ähnliche Funktionalität bereits im Userspace erreicht werden kann, sollte die Aufnahme in den Kernel vielleicht gar nicht akzeptiert werden. Jeder hat immer eine überzeugende Geschichte hinter einem Antrag, und es ist immer das "nächstbeste Ding" seit dem geschnittenen Brot. Der sprichwörtliche Teufel steckt in diesem Fall in den (Implementierungs-)Details.
So wie die Sicherheitslandschaft immer gefährlicher wird, ist es vielleicht an der Zeit, die Anforderungen für die Zulassung neuer Systeme zu verschärfen. Schließlich gibt es nur eine begrenzte Anzahl von Augäpfeln, die die Dinge im Auge behalten können.
Der Kernel besteht aus Hunderttausenden von Codezeilen, und es ist nicht möglich, all die seltsam schönen Wechselwirkungen zwischen dem ganz neuen Code und all den alten, abstoßenden Teilen, die noch aus den Anfangstagen übrig sind, zu berücksichtigen. Wer kann garantieren, dass ein neues Dateisystem, das hinzugefügt wird, nicht eine Sicherung durchbrennt, wenn es in einem System mit einem Scheduler verwendet wird, der kaum je benutzt wird? Sind die Testsuiten so gut, dass sie das berücksichtigen können? Oder ist das nur eine weitere Überraschung, die IT-Teams in der kommenden Urlaubssaison erleben werden?
Ich für meinen Teil würde gerne meinen Eierpunsch genießen, anstatt mir an Weihnachten Sorgen über Hacker in meinen Systemen zu machen.
