ClickCease Drei weitere Zombie-Kernel-Bugs beweisen, warum Sie konsequent patchen müssen - TuxCare

Abonnieren Sie unseren beliebten Newsletter

Schließen Sie sich 4.500+ Linux- und Open-Source-Experten an!

2x im Monat. Kein Spam.

Drei weitere Zombie-Kernel-Bugs beweisen, warum man konsequent patchen muss

16. März 2021. TuxCare PR Team

Drei weitere Zombie-Kernel-Fehler beweisen, warum Sie konsequent patchen müssen

Kürzlich tauchte eine altbekannte Sicherheitslücke namens Spectre wieder auf, da ein Exploit öffentlich zugänglich gemacht wurde und es an Patches mangelte, so dass diese bekannte Sicherheitslücke erneut eine Gefahr darstellt.

Und schon wieder ist etwas Ähnliches passiert. Diesmal fanden Sicherheitsforscher drei kritische Fehler in 15 Jahre altem Linux-Kernel-Code. Code, der so alt ist, hätte schon längst gründlich auf Fehler untersucht werden müssen - und es ist nur eine Frage der Zeit, wie oft diese Schwachstellen in der Zwischenzeit von böswilligen Akteuren ausgenutzt worden sind.

Patches wurden jetzt fürCentOS 8, Oracle EL8, RHEL8, CloudLinux 7h, CloudLinux 8, AlmaLinux OS, Ubuntu Bionic HWE, Debian 10, Debian 10 Cloud, Debian 9 Backports und Proxmox VE6 veröffentlicht.

Zusätzlich sind jetzt auch Patches für CloudLinux 6h, CloudLinux 7, CentOS 7, CentOS 7-plus, Oracle EL7 und RHEL 7 verfügbar.

In diesem Artikel gehen wir auf die drei gerade entdeckten Schwachstellen ein, erklären, warum Open-Source-Code nicht immer so gut geprüft wird, wie es sein sollte (oder von den richtigen Leuten), und weisen darauf hin, wie wichtig es ist, konsequent zu patchen.

Inhalt

  1. Der alte Code kommt zurück und sucht uns heim

  2. Offensichtliche Fehler in der Kodierung

  3. Sie sind verwundbar, auch wenn Sie kein SCSI verwenden

  4. Nur weil der Code quelloffen und frei einsehbar ist....

  5. Patching kann Ihre Server retten

  6. Automatisches Patching in Betracht ziehen

  7. Zeitplan für die Veröffentlichung von Patches

 

 

Der alte Code kommt zurück und sucht uns heim

 

Das Überraschende an vielen modernen Betriebssystemen ist, dass der zugrunde liegende Code ziemlich alt sein kann. Als sich Linux von seinen Ursprüngen im Jahr 1991 entwickelte, wurde der Kernel kontinuierlich aktualisiert, was jedoch nicht bedeutet, dass der Linux-Kernel von Grund auf neu geschrieben wurde. Es wurde Code hinzugefügt, aktualisiert und entfernt, aber nicht alles auf einmal.

Das hat zur Folge, dass die moderne, aktuelle Version des Linux-Betriebssystems, das Sie verwenden, Code enthalten kann, der Jahrzehnte alt ist. Und in mehr als zehn Jahre altem Code wurden drei Sicherheitslücken gefunden, die unter der Bezeichnung CVE-2021-27363, CVE-2021-27364 und CVE-2021-27365.

Wir werden in diesem Artikel nicht näher auf die drei Sicherheitslücken eingehen - Sie können den Originalbericht bei GRIMM lesen. Aber hier ist ein kurzer Überblick.

Die Forscher von GRIMM untersuchten, wie sie es ausdrücken, beiläufig Code im Linux-Kernel, als ihnen eine extrem auffällige Sicherheitslücke ins Auge sprang. In der Serie von drei Fehlern, die von dem Unternehmen gemeldet wurden, war der erste Fehler absolut offensichtlich. Er spiegelte auch ein mangelndes Bewusstsein für Sicherheitsrisiken zu der Zeit wider, als der Code geschrieben wurde.

Dieser Code war in allen Kernel-Versionen bis zu 5.11.3 vorhanden . Dies bedeutet, dass alle Linux-Distributionen und alle Versionen, die 15 Jahre zurückliegen, von Fehlern betroffen sind.

 

 

Offensichtliche Fehler in der Kodierung

 

Das Team von GRIMM fand ein Problem im Code des SCSI-Treibers. Es war ganz offensichtlich: Der Programmierer hatte es versäumt, einen Längenparameter anzugeben, als er char *buf in einem Bereich des Codes einfügte. Ohne Längenvalidierung könnte ein Angreifer diesen Code mit etwas Aufwand für einen Angriff ausnutzen.

Die zweite und dritte Schwachstelle befand sich im Linux iSCSI-Subsystem. Bei der zweiten verwendete der Programmierer eine Kernel-Adresse als Handle (was einem Angreifer die Umgehung der Kernel Address Space Layout Randomization) und bei der dritten versäumte der Programmierer die Validierung von Benutzerdaten im Kernel.

Alle drei Schwachstellen weisen auf gängige Programmierfehler hin, die zu Sicherheitsproblemen führen - zum Zeitpunkt der Erstellung des Codes waren sich die Programmierer dieser Probleme jedoch nicht so sehr bewusst. Heute ermöglichen diese Programmierfehler einem böswilligen Akteur die Ausführung eines lokalen Angriffs zur Ausweitung der Berechtigungen in mehreren Linux-Distributionen.

 

Sie sind verwundbar, auch wenn Sie kein SCSI verwenden

 

Die drei jüngsten Sicherheitslücken betreffen alle SCSI-Treiber. SCSI, die Abkürzung für Small Computer Systems Interface, ist ein Standard aus dem Jahr 1986 für den Anschluss von Computern und Peripheriegeräten. Er hat sich im Laufe der Jahre weiterentwickelt und wird immer noch über Standards wie Serial Attached SCSI (SAS) und iSCSI, das im Wesentlichen SCSI über TCP ist, verwendet.

Aber auch wenn Ihre Arbeitslast nicht von SCSI abhängt, können diese Sicherheitslücken Ihre Server beeinträchtigen. Der Grund dafür ist die Art und Weise, wie Linux-Kernel-Pakete voneinander abhängen. SCSI-Treibercode kann in den Speicher Ihres Servers geladen werden, auch wenn Sie kein SCSI-Gerät an Ihren Server angeschlossen haben, einfach aufgrund von Abhängigkeiten.

Ein einfaches Beispiel ist iSCSI, das nach wie vor eine zuverlässige Methode für den Zugriff auf zentralisierte Daten über ein Netzwerk darstellt. Wenn Ihr Server iSCSI aufruft, wird er wiederum den SCSI-Code aufrufen, in dem die Schwachstellen gefunden wurden. Dies geschieht automatisch, wenn der Linux-Kernel feststellt, dass eine Funktion in einem Modul benötigt wird, und das Modul lädt.

Bedrohungsakteure wiederum können sich auf die Tatsache verlassen, dass Module bei Bedarf automatisch geladen werden, um Schwachstellen in Code auszunutzen, den Sie vielleicht nie in Ihrem Arbeitsablauf verwenden.

 

Nur weil der Code quelloffen und frei einsehbar ist....

 

Die drei soeben aufgeführten Schwachstellen weisen einen interessanten Aspekt auf. Open-Source-Code ist per definitionem offen für Überprüfungen. Der Code wird im öffentlichen Bereich veröffentlicht und kann frei eingesehen und ausprobiert werden.

Zumindest theoretisch könnte dies bedeuten, dass quelloffener Code sehr sicher ist, weil er so offen für Überprüfungen ist. Dies ist die Annahme, die viele Menschen über Open-Source-Code machen.

Die drei von uns besprochenen Sicherheitslücken wurden jedoch in Code gefunden, der seit 15 Jahren Teil des Linux-Kernels ist. Man sollte meinen, dass diese unübersehbaren Schwachstellen schon vor langer Zeit gefunden worden wären - aber das waren sie nicht.

In gewisser Weise ist die Annahme, dass Open-Source-Code sicherer ist, weil er einer Überprüfung unterzogen werden kann, also weniger stichhaltig, als es auf den ersten Blick scheint.

Auf der anderen Seite ist es auch schwer zu sagen, ob irgendwelche Advanced Persistent Threat (APT) Akteure diese Schwachstellen vor den White-Hat-Sicherheitsforschern gefunden haben, und was sie mit diesem Wissen gemacht haben. Die schiere Menge der Linux-Kernel-Schwachstellen, die jedes Jahr entdeckt werden deutet auch darauf hin, dass es noch viele unbekannte Schwachstellen gibt, die zu Sicherheitsverletzungen führen könnten.

 

Patching kann Ihre Server retten

 

Die Sicherheitslücken im Linux-Kernel häufen sich, und offenbar kann auch 15 Jahre alter Code noch für Überraschungen sorgen. Sie können zwar keine Patches für Schwachstellen erstellen, die noch nicht von Sicherheitsforschern entdeckt wurden, aber Sie können Patches für Schwachstellen und die dazugehörigen Exploits erstellen, die bereits öffentlich bekannt sind. Dies nicht zu tun, wäre töricht.

Das Patchen gegen bekannte Schwachstellen macht Ihr System auch härter. Selbst wenn es einem Akteur gelingt, über eine von Forschern noch nicht entdeckte Schwachstelle in Ihr Netz einzudringen, wird eine seitliche Bewegung schwieriger, wenn Ihre Systeme konsequent gegen bekannte Schwachstellen gepatcht sind.

Aber wie wir alle wissen, ist ein konsistentes Patching einfach nicht einfach. Oft sind Neustarts erforderlich, die Server müssen abgeschaltet werden und die Dienste werden unterbrochen. Hinzu kommen die damit verbundenen Arbeitsstunden - das Patchen kostet Zeit. Aus diesem Grund wird das Patchen oft vernachlässigt.

 

Automatisches Patching in Betracht ziehen

 

Unternehmen, die auf Linux-basierte Betriebssysteme angewiesen sind, haben die Möglichkeit, automatische Patches zu installieren, wodurch die Notwendigkeit entfällt, Betriebssystem-Patches manuell anzuwenden.

Im Falle der KernelCare automatisierte Patching-Lösungbietet sie den zusätzlichen Vorteil des Live-Patchings ohne Neustart. Mit anderen Worten: KernelCare kann Ihre Server automatisch und live patchen, ohne dass ein Neustart des Servers erforderlich ist.

Unabhängig davon, für welchen Weg Sie sich entscheiden - sorgfältiges manuelles Patchen oder ein Live-Patching-Tool wie KernelCare - ist es von entscheidender Bedeutung, dass Sie konsequent patchen, um Ihren Workload vor bestehenden und neuen Bedrohungen zu schützen.

 

Zeitplan für die Veröffentlichung von Patches

Das KernelCare-Team arbeitet derzeit an Patches für diese Sicherheitslücken, die keinen Neustart erfordern. Die ersten Patches werden voraussichtlich am 18. März verteilt. Behalten Sie diesen Blog-Beitrag im Auge, um ein Update zu erhalten, wenn die Patches veröffentlicht werden.

Möchten Sie das Patchen von Sicherheitslücken ohne Kernel-Neustart, Systemausfallzeiten oder geplante Wartungsfenster automatisieren?

Erfahren Sie mehr über Live-Patching mit TuxCare

Werden Sie ein TuxCare-Gastautor

Los geht's

E-Mail

Beitreten

4,500

Linux & Open Source
Fachleute!

Abonnieren Sie
unseren Newsletter