ClickCease Neue Kernel-Schwachstelle bei Virtuozzo gefunden und von KernelCare live gepatcht - TuxCare

Abonnieren Sie unseren beliebten Newsletter

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

2x im Monat. Kein Spam.

Neue Kernel-Schwachstelle bei Virtuozzo gefunden und von KernelCare live gepatcht

2. Juli 2020. TuxCare PR Team

Neue Kernel-Schwachstelle bei Virtuozzo Live gefunden - gepatcht von KernelCare

Vor einem Monat entdeckte das Virtuozzo-Teameine neue Sicherheitslücke im Kernel - CVE-2020-14305. Sie korrumpiert den Speicher in Kerneln von v3.5 bis v4.10 und betrifft verschiedene Linux-Distributionen. KernelCare bereitet die Patches für diese CVE vor, die noch in dieser Woche verfügbar sein werden. Lesen Sie diesen Artikel, um zu erfahren, wie die Sicherheitslücke entdeckt wurde und welche Abhilfemaßnahmen es gibt.

Eine CVE-Schwachstelle für Speicherkorruption (CVE-2020-14305) wurde Anfang Juni vom Linux-Kernel-Ingenieur von Virtuozzo, Vasily Averin, entdeckt. Die Sicherheitslücke betrifft verschiedene Linux-Distributionen: Red Hat Enterprise Linux 7, Debian 8 & 9, Ubuntu 14.04 und 16.04, UEK 3 & 4, Centos 7 ALT und Kernel von 3.5 bis 4.10. Wenn der IPV6-Port 1720 auf dem Knoten offen ist, beschädigt die Verbindung zu ihm den Speicher. Insbesondere das FastVPS-Team - der Nutzer, der diesen Fehler dem Virtuozzo-Team gemeldet hat - hat die Korruption eines Elements im kmalloc-192-Slab erfahren. Die Sicherheitslücke ist in Virtuozzo Hybrid Server 7.0 Update14 und ReadyKernel 108 behoben.

 

Laut RedHat wird dieses Problem als mäßige Auswirkung eingestuft, da es nur auf die Verwendung von IPV6 Port 1720 und eines bestimmten Moduls für Voice Over IP H.323 beschränkt ist.

Um dieses Problem zu beheben, hat das Virtuozzo-Team einen Patch für Virtuozzo 7 erstellt und das KernelCare-Team hat die Patches für andere betroffene Linux-Distributionen für die rebootlose Verteilung erstellt.

Das KernelCare-Team möchte dem Virtuozzo-Team und Vasily Averin dafür danken, dass sie diesen Fehler gefunden und uns die Möglichkeit gegeben haben, unseren Kunden die Patches gegen CVE-2020-14305 so schnell zur Verfügung zu stellen.

 

Zeitplan für die Veröffentlichung von KernelCare-Patches

 

Hier ist ein Zeitplan für die Veröffentlichung von KernelCare-Patches:

  • Montag, 6. Juli: RHEL7, Debian8 & 9, Ubuntu 14.04 & 16.04, 
  • Donnerstag, 9. Juli: Unbreakable Enterprise Kernel 3 & 4, CentOS 7.

 

Anweisungen zur Schadensbegrenzung

 

Für das Patchen dieser Sicherheitslücke ist keine besondere Abschwächung erforderlich. Wenn Ihr Kernel betroffen ist und Sie KernelCare verwenden, werden die Patches automatisch auf der Grundlage Ihrer Update-Einstellungen angewendet (standardmäßig prüft der KernelCare-Agent alle 4 Stunden auf Patches).

Wenn Sie Ihr KernelCare verwenden, werden Ihre Patches automatisch von KernelCare geliefert und Sie müssen nichts weiter tun. Wenn nicht - dann ist jetzt der richtige Zeitpunkt, um sich für eine 30-tägige Testversion anzumelden. Es ist keine Kreditkarte erforderlich.

 

Wie wurde CVE-2020-14305 entdeckt?

Das Virtuozzo-Team hat KernelCare die exklusiven Details zur Verfügung gestellt, wie dieses CVE entdeckt wurde. Dies wurde mit Hilfe ihres Kunden - dem FastVPS-Team - möglich. 

"Ich möchte dem FastVPS-Team für die Meldung dieses Bugs, ihr Engagement, ihre Geduld und ihre Zusammenarbeit in dieser Hinsicht danken. Ohne ihre Mitarbeit wäre diese Schwachstelle vielleicht gar nicht entdeckt worden", sagte Vasily Averin, Linux Kernel Engineer bei Virtuozzo.

Lesen Sie weiter, um die ganze Geschichte zu erfahren. 

Beim Durchsuchen der Crash-Dumps fand das Virtuozzo-Team eine Ursache für die Abstürze heraus - es handelte sich um eine Speicherkorruption im kmalloc-192-Slab, wo verschiedene Kernel-Objekte von 128 bis 192 Bytes gespeichert werden. Sie haben bereits früher Berichte über solche Objekte erhalten, aber jedes Mal stießen die Untersuchungen auf eine Mauer.

Es war sehr schwierig, die Beschädigung des Speichers zu untersuchen, weil sie in der Natur der Sache liegt. Oft entziehen sich Speicherbeschädigungen einfach der Entdeckung, z. B. wenn ungenutzter Speicher beschädigt ist. Manchmal kann man Glück haben, wenn die Korruption nichts Kritisches beschädigt. Aber selbst wenn sie zu einem Kernel-Crash führt, ist es schwer nachzuvollziehen, dass der Grund für den Crash eine Speicherbeschädigung war.

Noch schwieriger ist es, die Art der Beschädigung zu verstehen. In der Regel ist dies auf use-after-free zurückzuführen, und daher müssen Sie die Zuweisung, Initialisierung, Referenzzählung und Freigabe beschädigter Objekte überprüfen. Im Fall der kmalloc-192-Platte ist es jedoch noch schlimmer - sie wird verwendet, um viele verschiedene Objekte zu speichern. Das Virtuozzo-Team hat versucht, die beliebtesten aufzuspüren und ist gescheitert.

Von Zeit zu Zeit fand das Virtuozzo-Team jedoch etwas. Im Februar entdeckte Vasily einen Fehler, der eine Speicherbeschädigung in kmalloc-192 verursachte.

Er hoffte, dass er das Problem behoben hatte. Aber eines Tages kam FastVPS mit dem gleichen Problem. Vasily's Team bat sie, das Problem auf dem Kernel mit dem oben genannten Fix zu reproduzieren, aber das half nicht, das Problem wiederholte sich.

Normalerweise verwendet Virtuozzo in solchen Fällen den Kernel-Debug mit dem zusätzlichen Allzweck-Debug. Kunden verwenden keine Debug-Kernel in der Produktion, da dies die Leistung dramatisch verringert und für unsere Hosts völlig inakzeptabel ist. FastVPS hat jedoch den Debug-Kernel in die Produktion übernommen. Es hat einige Zeit gedauert, aber da sich das Problem nicht reproduzierte, wurde wieder auf den regulären Kernel umgestellt.

Um das Problem auf dem regulären Kernel zu erkennen, bat Virtuozzo FastVPN, slub_debug zu aktivieren

Es verringert auch die Leistung und erhöht den Speicherverbrauch, führt zusätzliche Speicherprüfungen beim Zuweisen und Freigeben von Objekten durch und ermöglicht es Ihnen, zu verfolgen, wie ein beschädigtes Objekt in der Vergangenheit verwendet wurde. Dennoch konnte das Problem nicht reproduziert werden und die Knoten mit aktiviertem slub_debug liefen gut. Aber schließlich erhielt das Virtuozzo-Team Anfang Juni einen Bericht von dem Knoten mit aktiviertem slub_debug. Aus diesem Bericht ging hervor, welches Objekt die Speicherbeschädigung verursachte und auch die Art der Beschädigung - es handelte sich nicht um use-after-free, sondern um das wesentlich seltenere access-beyond-end-of-object.

Dies trug wesentlich zur Untersuchung bei, und ein paar Tage später fand Vasily die Ursache des Problems.

 

Um zu erfahren, wann der Patch verfügbar ist, verfolgen Sie diesen Blogbeitrag oder unsere Twitter und Facebook Kanäle.

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