ClickCease Mmap-Kernel-Schwachstelle wird neu gelistet - TuxCare

Abonnieren Sie unseren beliebten Newsletter

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

2x im Monat. Kein Spam.

Mmap-Kernel-Schwachstelle wird neu gelistet

3. März 2021. TuxCare PR Team

Die Mmap-Kernel-Schwachstelle wird neu gelistet - und was das für das Schwachstellenmanagement bedeutet

In einigen unserer früheren Artikel haben wir brandneue Sicherheitslücken im Linux-Kernel behandelt, aber in diesem Artikel werfen wir einen Blick auf eine Sicherheitslücke, die versehentlich neu gelistet wurde. Beide Berichte - die irrtümliche Neulistung und die ursprüngliche Listung - weisen auf eine Schwachstelle im Linux-Kernel-Speicher-Mapping hin, bei der eine Race Condition entstehen kann, wenn eine Speichererweiterungsfunktion verwendet wird.

Wir werden die Schwachstelle in ihrer jetzigen Form behandeln. Wir werden uns aber auch mit einem wichtigen Problem befassen, das durch die doppelte Auflistung aufgedeckt wird: Wenn Sicherheitsexperten eine bestehende Schwachstelle so leicht aus den Augen verlieren können, dass eine Schwachstelle erneut als "neu" und "gerade erst entdeckt" aufgeführt wird - was sagt das über den Zustand des Schwachstellenmanagements aus?

Und was bedeutet das für Linux-Benutzer auf der ganzen Welt, die durch zahllose Angriffsstrategien gefährdet sind - aber auf die Hilfe von Sicherheitsexperten angewiesen sind?

 

Inhalt

  1. Verständnis der mmap-Kernel-Schwachstelle

  2. Speichererweiterung

  3. Ein kurzer Überblick über die Rennbedingungen und die Verwendung nach dem Freifahren

  4. Welche Auswirkungen hat diese besondere Schwachstelle?

  5. Warte, wir waren schon mal hier...

  6. Es geht um ein größeres Problem

  7. Ein wirksames Schwachstellenmanagement ist extrem schwierig

  8. Wirksamer Umgang mit Schwachstellen

  9. Patching ist entscheidend

  10. Automatisiertes Live-Patching ist der Schlüssel

  11. Schlussfolgerung

Verständnis der mmap-Kernel-SchwachstelleVerständnis der mmap-Kernel-Schwachstelle

 

Anwendungen müssen fast immer etwas im Computerspeicher halten, während die Anwendung läuft - sonst wären sie nicht sehr nützlich. Im Gegenzug muss der Kernel des Betriebssystems einer Anwendung Speicherplatz zuweisen. Die Funktion, mit der diese Speicherzuweisung angefordert wird, heißt mmap, eine Speicherzuordnungsfunktion.

Natürlich gibt es in jedem Computer eine endliche Menge an Speicher. Bei der Zuweisung von Speicher muss der Kernel den Bedarf sorgfältig verwalten - und bei Bedarf ungenutzten Speicher einer anderen Anwendung zuweisen.

Bei dieser speziellen Sicherheitslücke gibt es einen Grenzfall, bei dem zwei verschiedene Anwendungen Zugriff auf denselben Speicher anfordern könnten. Die Anwendung, die als letzte dran ist, wird mit ihrer Anfrage scheitern. Der Grund für die Schwachstelle liegt darin, dass diese zweite Anwendung immer noch in der Lage wäre, von einem nun ungültigen Speicherplatz zu lesen.

Dies würde wiederum einen Kernel-Absturz auslösen, was bedeuten könnte, dass die Informationen in diesem Speicherplatz offengelegt werden. Die Informationen könnten alles Mögliche beinhalten, von etwas völlig Harmlosem bis hin zu einem Verschlüsselungsschlüssel - und genau darin liegt das Risiko.

 

Speichererweiterung

Speichererweiterung

 

Es ist erwähnenswert, dass die Ursache für diese Sicherheitslücke in der Art und Weise liegt, wie die Speichererweiterung gehandhabt wird. Der Kernel verwaltet den zugewiesenen Speicher, indem er eine Liste von Speicherseiten führt. Gelegentlich kann eine Anwendung mehr Speicher benötigen - oder sogar einen Teil dieses Speichers abgeben.

Wenn der Benutzer einer Anwendung beispielsweise eine große Datei öffnet, muss die Anwendung möglicherweise ihre Speicherzuweisung erweitern. Diese Erweiterung kann "nach oben" oder "nach unten" gegenüber dem bereits zugewiesenen Speicher erfolgen. Normalerweise wäre dies kein Problem, aber die Erweiterung muss sorgfältig gehandhabt werden, da es sonst zu Problemen kommen kann - Interaktionen können zwischen mehreren Threads derselben Anwendung oder in verschiedenen Anwendungen auftreten.

Wie die Forscher, die diese Schwachstelle entdeckten, feststellten, handhaben die betroffenen Versionen des Linux-Kernels die Speichererweiterung in einigen Fällen leider nicht korrekt. Aufgrund dieser Schwachstelle kann eine Wettlaufsituation zwischen bestimmten Expansionsfunktionen - expand_downwards und expand_upwards - und Operationen zur Freigabe von Seitentabellen entstehen.

 

Ein kurzer Überblick über die Rennbedingungen und die Verwendung nach dem Freifahren

Ein kurzer Überblick über die Rennbedingungen und die Verwendung nach dem Freifahren

 

Es lohnt sich, kurz auf die beiden allgemeinen Sicherheitsprobleme einzugehen, die diese Sicherheitslücke umgeben. Erstens: Viele Sicherheitsprobleme drehen sich um Race Conditions. Wir haben oben beschrieben, wie die Race Condition bei dieser Schwachstelle funktioniert - zwei Anwendungen fordern Zugriff auf denselben Speicherbereich an. Die Anwendung, die "zu spät" eintrifft, kann fälschlicherweise Zugriff auf Speicher erhalten, der einer anderen Anwendung zugewiesen wurde.

Dies ist nur ein Beispiel für eine Race Condition. Im Allgemeinen treten Race Conditions auf, wenn zwei oder mehr Threads - aus derselben oder aus verschiedenen Anwendungen - versuchen, auf dieselben Daten zuzugreifen. Dabei kann es sich um gemeinsam genutzte Daten oder auch um einen zugewiesenen Speicherplatz handeln. Angreifer können die durch Race Conditions verursachten Fehler (einschließlich Kernel-Crashs) für eine Reihe von Angriffen ausnutzen - von Denial-of-Service bis zum Abschöpfen von Daten.

Ein User-after-free- oder UAF-Szenario liegt vor, wenn eine Anwendung versucht, auf einen Teil des Speichers zuzugreifen, nachdem dieser freigegeben wurde. Beispielsweise verweist ein Zeiger in einer Anwendung auf einen Datensatz im dynamischen Speicher, der nicht mehr verwendet wird - und daher frei ist -, obwohl der Zeiger eigentlich hätte aktualisiert werden müssen.

Auch hier bieten UAF-Schwachstellen Angreifern die Möglichkeit, Programmierfehler auszunutzen, um einen Sicherheitsverstoß zu begehen - ein System zum Absturz zu bringen oder Daten zu stehlen.

 

Welche Auswirkungen hat diese besondere Schwachstelle?

Welche Auswirkungen hat diese besondere Schwachstelle?

 

Derzeit sind keine Exploits für diese Sicherheitslücke bekannt, aber wie immer besteht das Risiko, dass ein Exploit auftauchen kann. Das Risiko ist mittel bis gering, da zum Ausnutzen der Schwachstelle ein lokales Konto erforderlich ist. Nichtsdestotrotz kann ein Angreifer mit lokalem Kontozugriff ein speziell codiertes Programm erstellen, das einen Use-after-free auslöst und den Kernel zum Absturz bringt.

Als Nebeneffekt dieses Absturzes kann der Angreifer sein Programm so gestalten, dass er Informationen stiehlt, indem er z. B. die durch den Absturz erzeugte Fehlermeldung abgreift, die den Inhalt des betroffenen Speichers enthält. Angreifer können auch auf den "Core Dump" verweisen, der bei jedem Absturz des Kernels erstellt wird. Ein richtig ausgeführter Angriff kann diese Informationen auf einen anderen Rechner schleusen.

Diese Sicherheitslücke betrifft Kernel-Versionen vor 5.7.11. Die meisten Distributionen haben Korrekturen für die Sicherheitslücke veröffentlicht - wenn Sie die entsprechenden Patches eingespielt haben, sind Ihre Workloads vor dieser Sicherheitslücke geschützt. Und natürlich bietet KernelCare Live-Patches für diese Sicherheitslücke für alle von ihm unterstützten Distributionen an.

 

Warte, wir waren schon mal hier...

Warte, wir waren schon mal hier...

 

Die CVE für die betreffende Sicherheitslücke, CVE-2020-20200wurde vor kurzem als reserviert eingestuft (d. h., eine Sicherheitslücke wurde möglicherweise identifiziert, aber nicht bestätigt). Wie sich herausstellte, handelte es sich um eine doppelte Meldung. Genau dieselbe Sicherheitslücke wurde bereits im November letzten Jahres als CVE-2020-29369.

Die Forscher, die CVE-2020-20200 reserviert haben, wussten offensichtlich nicht, dass die Schwachstelle bereits gemeldet worden war. Infolgedessen wurde CVE-2020-20200 einfach in CVE-2020-29369 eingefügt. Es ist nicht das erste Mal, dass eine Sicherheitslücke doppelt gemeldet wurde, und dieses jüngste Beispiel rückt die Frage der doppelten Meldung - und was sie bedeutet - wieder ins Rampenlicht.

Selbst Leute, die sich intensiv mit der Sicherheit des Linux-Kernels beschäftigen, haben die zweite Offenlegung akzeptiert. Ja, es ist positiv, dass verschiedene Personen und Teams nach diesen Schwachstellen suchen, aber es ist besorgniserregend, dass bestehende Schwachstellen dabei so leicht vergessen werden können.

 

Es geht um ein größeres Problem

Es geht um ein größeres Problem

 

Man kann argumentieren, dass die doppelte Meldung auf ein mangelndes Bewusstsein für Sicherheitslücken in der breiteren Sicherheitsgemeinschaft hinweist. Diese spezielle Schwachstelle betrifft grundlegende Kernel-Funktionen, aber die Tatsache, dass sie zweimal gemeldet wurde, deutet darauf hin, dass ihre Existenz nicht so weit bekannt ist, wie sie es hätte sein sollen.

Es ist leicht, den Sicherheitsexperten die Schuld an mangelndem Bewusstsein zu geben, aber Tatsache ist, dass diese Personen und Teams einfach in einer Flut von Sicherheitslücken untergehen. Die wachsende Welle von Sicherheitsproblemen schwemmt einfach jede reale Möglichkeit für eine einzelne Person oder sogar ein Team weg, konsequent auf kritische, gemeldete Schwachstellen zu achten.

Mit anderen Worten, wir sagen, dass selbst die Experten die Flut der entdeckten Schwachstellen nicht mehr bewältigen können.

 

Ein wirksames Schwachstellenmanagement ist extrem schwierig

Ein wirksames Schwachstellenmanagement ist extrem schwierig

 

Wenn sich Sicherheitsexperten mit der Verwaltung von Schwachstellen schwer tun, ist es selbstverständlich, dass die für den täglichen IT-Betrieb verantwortlichen Mitarbeiter noch mehr zu kämpfen haben. Ein typischer Systemadministrator ist bereits mit seinen täglichen Aufgaben überfordert - er kann sich mit Glück an die letzten fünf oder zehn Schwachstellen erinnern, die kürzlich gepatcht werden mussten. Aber Dutzende oder Hunderte? Das ist unwahrscheinlich.

In der Praxis bedeutet dies, dass Schwachstellen nur unzureichend verwaltet werden. Viele Schwachstellen werden einfach unter dem Radar verschwinden. Andere werden gepatcht werden - aber höchstwahrscheinlich lange nach der Veröffentlichung des Patches.

Diese "unvollkommene" Behandlung von Schwachstellen ist es, die böswilligen Akteuren eine Chance gibt. Schlimmer noch, Angreifer verwenden häufig automatisierte Tools, um nach ungepatchten Schwachstellen zu suchen. Mit anderen Worten: Stückweises Patchen ist nicht viel anders als gar kein Patchen.

 

Wirksamer Umgang mit Schwachstellen

Wirksamer Umgang mit Schwachstellen

 

Das Schwachstellenmanagement profitiert von einer Reihe von Instrumenten. Ein wichtiges Instrument wäre zum Beispiel die genaue Verwaltung von Anmeldedaten und Berechtigungen, um den Schaden zu begrenzen, den ein Angreifer mit gestohlenen Anmeldedaten anrichten kann.

In ähnlicher Weise kann die Sicherheitsüberwachung dazu beitragen, einen laufenden Angriff zu erkennen und Ihnen die Möglichkeit zu geben, den Schaden zu begrenzen. Und natürlich können Firewalls und andere Sicherheitstools automatische Angriffe stoppen, bevor diese Wurzeln schlagen.

 

Patching ist entscheidend

Patching ist entscheidend

 

Dennoch ist ein konsequentes und schnelles Patchen der bei weitem effektivste Weg, um Sicherheitslücken zu schließen. In vielen Fällen wird ein Patch für eine Sicherheitslücke veröffentlicht, lange bevor ein Exploit auftaucht. Selbst in Fällen, in denen die Schwachstelle bereits bekannt ist, bevor ein Patch zur Verfügung steht, ist das Zeitfenster zwischen Exploit und Patch relativ klein.

Im Gegensatz dazu kann bei ineffektivem Patching das Zeitfenster zwischen dem Auftauchen eines Exploits und dem Einspielen des Patches Jahre betragen - oder unendlich lang sein.

Wir wissen, dass das Patchen schwierig ist. Patches sind zum Beispiel störend und erfordern oft einen Neustart des Servers. Patches während der Wartungsfenster sind hilfreich, aber kritische Patches müssen auch außerhalb eines Wartungsfensters angewendet werden.

 

Automatisiertes Live-Patching ist der Schlüssel

Automatisiertes Live-Patching ist der Schlüssel

 

Manuelles Patching ist zeitaufwändig. Automatisiertes Patching ist ein besserer Weg - es stellt sicher, dass Patches konsistent und ohne die übliche Belastung der IT-Ressourcen eingespielt werden.

Die effektivste Art, Patches zu verwalten, ist natürlich das automatisierte Patching in Kombination mit Patches ohne Neustart. Mit anderen Worten: Patches, die live angewendet werden, ohne dass ein Neustart erforderlich ist. Live-Patching ohne Neustart bedeutet, dass die Server auf dem neuesten Stand gehalten werden, ohne die zugrunde liegenden Dienste zu unterbrechen.

Dieser Dienst ist das, was KernelCare Live-Patching ist ein automatischer, nahtloser Patching-Service für Ihre Server, der keine störenden Neustarts erfordert.

Schlussfolgerung

Schlussfolgerung

 

Die Flut von Sicherheitslücken ist extrem schwer zu überblicken. Selbst die Experten, die sich am intensivsten mit der Verwaltung von Sicherheitslücken befassen, machen manchmal Fehler. Es steht daher außer Frage, dass Systemadministratoren und Sicherheitsexperten in Unternehmen ähnliche Fehler begehen, es sei denn, sie verwenden hochmoderne, automatisierte Tools.

Das Live-, rebootlose und automatisierte Patching von KernelCare wendet Patches für die oben genannte mmap-Schwachstelle und viele andere Arten von Schwachstellen an, sobald der Patch veröffentlicht wird. Tools wie KernelCare sind daher im laufenden Kampf gegen Schwachstellen - und die damit verbundenen Exploits - von entscheidender Bedeutung.

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