Über CVE-2024-0517
CVE-2024-0517 ist eine Sicherheitslücke durch einen Schreibvorgang außerhalb des zulässigen Bereichs in der V8-JavaScript-Engine von Google Chrome vor Version 120.0.6099.224, die es Angreifern aus der Ferne ermöglicht, über eine manipulierte HTML-Seite eine Heap-Korruption auszunutzen. Die Sicherheitslücke wurde erstmals von Toan (Suto) Pham von Qrious Secure gemeldet.
Diese Schwachstelle entsteht durch Typverwechslung, die auftritt, wenn eine Anwendung eine Ressource wie einen Zeiger, ein Objekt oder eine Variable unter Verwendung eines Typs zuweist oder initialisiert, aber später auf diese Ressource unter Verwendung eines Typs zugreift, der mit dem ursprünglichen Typ nicht kompatibel ist (CWE-843). In diesem CVE wird die Typverwechslung während eines Speicherzuweisungsprozesses ausgelöst, der als gefaltete Zuweisung bezeichnet wird und von Maglev, einem optimierenden Compiler für die V8 JavaScript-Engine, zur Speicheroptimierung eingesetzt wird.
Durch Ausnutzung der Typverwirrung und Schreiben von beliebigem Shellcode durch WebAssembly kann ein Angreifer Befehle auf dem Rechner des Opfers ausführen.
Phasen des Angriffs
Angreifer können eine Website mit einer manipulierten HTML-Seite hosten und Nutzer über Phishing-E-Mails oder soziale Netzwerke dazu verleiten, darauf zuzugreifen. Wenn die Nutzer die Seite mit einer anfälligen Version von Google Chrome besuchen, führt der eingebettete Schadcode beliebige Befehle aus.
V8-JavaScript-Engine
Die V8 JavaScript-Engine wurde von Google in C++ geschrieben und am 2. September 2008 veröffentlicht.V8 kompiliert und führt JavaScript-Quellcode aus, verwaltet die Speicherzuweisung für Objekte und sammelt nicht mehr benötigte Objekte ein. V8 ist eine Kernkomponente von Google Chrome und kann in jede C++-Anwendung, wie z. B. Node.js, eingebettet werden, um JavaScript- oder WebAssembly-Code auszuführen.
Magnetschwebebahn und gefaltete Zuteilung
Maglev, ein optimierender Compiler in V8, verbessert die Codeausführung und Speicherzuweisung. Maglev wird nur ausgeführt, wenn der Code häufig ausgeführt und als "heiß" markiert wird, was auf die Notwendigkeit einer schnelleren Ausführung durch Kompilierung anstelle der langsameren zeilenweisen Interpretation hinweist.
Normalerweise erfolgen Zuweisungen in nicht zusammenhängenden Speicherbereichen, was zu einer spärlichen und ineffizienten Speichernutzung führt. Um dieses Problem zu lösen, verwendet V8 eine Technik namens gefaltete Zuweisung, die mehrere Variablen kontinuierlich und gleichzeitig zuweist. Auch Maglev optimiert die Zuweisungen, indem es die gefaltete Zuweisung in seinem Prozess verwendet.
Generative Müllabfuhr
Um ungenutzte Speicherbereiche zu bereinigen, verwendet V8 eine Generational Garbage Collection (GC) Technik, die den Speicher in zwei Bereiche unterteilt: die junge Generation und die alte Generation. Außerdem gibt es zwei Garbage Collectors: den Minor Garbage Collector, der für die Bereinigung des Young Space zuständig ist, und den Major Garbage Collector, der die Bereinigung des Old Space übernimmt. Die junge Generation ist der Bereich des Speichers, in dem neu erstellte Objekte anfänglich zugewiesen werden, und die alte Generation ist ein Bereich des Speichers, in dem langlebige Objekte gespeichert werden. Objekte, die mehrere kleinere GC-Zyklen in der jungen Generation überlebt haben, werden schließlich in die alte Generation verschoben.
Schwachstellenanalyse
Übersicht
Die Schwachstelle tritt auf, wenn ein Objekt aus einer von einer Basisklasse geerbten Klasse ohne explizit definierten Konstruktor (Basis-Standardkonstruktor) erstellt wird und anschließend ein weiteres Objekt erstellt wird. Aufgrund der gefalteten Zuweisung kann auf die Zuweisung des ersten Objekts die Zuweisung des zweiten Objekts folgen. Tritt zwischen diesen beiden Zuweisungen ein Ereignis wie z.B. eine Garbage Collection ein, kann eine Typverwechslungsschwachstelle entstehen.
Analyse der Grundursache
OPSWAT Graduate Fellows führten eine detaillierte Analyse des V8-Workflows während des Zuteilungsprozesses durch und stellten fest, dass die folgenden Funktionen während dieses Prozesses aufgerufen werden:
In diesem Prozess wurde ein Problem in der Funktion TryBuildFindNonDefaultConstructorOrConstruct festgestellt: Die Funktion BuildAllocateFastObject erweitert current_raw_allocation_ (ein Zeiger auf den Speicherbereich, der für mehrere Variablen gleichzeitig zugewiesen wird), um die Instanz der Kindklasse zu konstruieren, kann diese aber nicht löschen, indem sie auf null gesetzt wird.
Infolgedessen wird das nächste erstellte Objekt immer unmittelbar nach dem Speicher, auf den current_raw_allocation_ verweist, zugewiesen, unabhängig von allen Ereignissen vor der zweiten Zuweisung.
Wenn GC aufgerufen wird, kann der Speicherbereich neben dem an current_raw_allocation_ angrenzenden Speicher anderen Objekten zugewiesen werden. Dies kann zu einer Situation führen, in der nach dem Auslösen von GC und der Erstellung eines anderen Objekts zwei Zeiger auf denselben Speicherbereich verweisen, aber unterschiedliche Datentypen haben, was zu einer Typverwechslungsschwachstelle führt.
Ausbeutung
Um diese Schwachstelle auszunutzen, erstellten OPSWAT WebAssembly-Instanzen, die Shellcode enthielten, und versuchten, eine Typverwechslung durch GC auszulösen, um den Speicher zu kontrollieren und den Shellcode auszuführen:
Auslösertyp-Verwirrung
Während der Initialisierung definieren wir zunächst ein Array (_arrayObject), das leere Objekte enthält. Als nächstes konstruieren wir eine Instanz der Child-Klasse sowie einen Trigger-Garbage-Collector. Schließlich definieren wir ein weiteres Array mit einer Fließkommazahl, das _arrayDouble heißt.
Diese Konstruktionen müssen wiederholt werden, so dass der Code mehrfach ausgeführt wird, was V8 veranlasst, ihn als "heiß" zu markieren und den Maglev-Compiler auszulösen. Wir erreichen dies, indem wir den Konstruktor der Kindklasse innerhalb einer Schleife wie folgt aufrufen:
Eine Typenverwechslung wird nach wiederholter Initialisierung dieser Objekte in einer Schleife ausgelöst.
Lese- und Schreibprimitive erstellen
Nach erfolgreicher Auslösung der Typenverwechslung muss der Shellcode ausgeführt werden, indem der Speicher gelesen und an einer kontrollierten Adresse überschrieben wird. Zu diesem Zweck haben wir Lese- und Schreibprimitive entwickelt. Exploit-Primitive nutzen die Metadaten in den Objekten, um uns beliebige Lese-/Schreib-Speicherbereiche zu geben und diese zur Ausführung von beliebigem Code zu verwenden.
Lese- und Schreibprimitive in diesem Schritt ermöglichen es uns, den Sprungtabellenzeiger der WebAssembly-Instanz im folgenden Schritt zu steuern.
WebAssembly-Instanzen erstellen
Als Nächstes haben wir zwei WebAssembly-Instanzen erstellt: eine zum Speichern des Shellcodes und eine weitere zum Auslösen des Shellcodes. Um zu vermeiden, dass der Shellcode über Lese- und Schreibprimitive direkt in den Speicher der WebAssembly-Instanz geschrieben wird, definieren wir einige Fließkomma-Konstantenwerte innerhalb der WebAssembly-Instanz.
Steuersprungtabellenzeiger der WebAssembly-Instanz
Mithilfe von Lese- und Schreibprimitiven passen wir den Sprungtabellenzeiger der zweiten WebAssembly-Instanz so an, dass einige Bytes des kompilierten Codes der Konstanten in der ersten WebAssembly-Instanz übersprungen werden, so dass die Fließkommakonstanten als unser beabsichtigter Shellcode interpretiert werden:
Ausführen der WebAssembly-Instanz zum Ausführen des Shellcodes
Nach dem Auslösen der Typverwechslung und der Verwendung von Lese-/Schreibprimitiven zur Steuerung der Sprungtabellenzeiger der WebAssembly-Instanzen haben wir schließlich die exportierte Funktion der zweiten WebAssembly-Instanz aufgerufen, die die Ausführung des Shellcodes in der ersten WebAssembly-Instanz bewirkt.
Der Shellcode, den wir verwenden, ist so konzipiert, dass er alle Prozesse auf einem Linux-Rechner beendet, wie durch den folgenden Befehl:
Der Assemblercode zur Ausführung dieses Befehls, der aus den Fließkommazahlen umgewandelt wird, lautet wie folgt:
Simulieren Sie die Sicherheitslücke
Um diesen Angriff in einem realen Szenario zu simulieren, erstellten die OPSWAT eine bösartig gestaltete HTML-Seite.
Das Opfer erhält eine Phishing-E-Mail, die einen Link zu der Domäne enthält, die diese manipulierte HTML-Seite hostet.
Wenn das Opfer über die verwundbare Version von Google Chrome auf den Link zugreift, wird der Shellcode ausgeführt, wodurch alle Prozesse beendet werden. Infolgedessen wird der Benutzer abgemeldet, wie unten dargestellt:
Sanierung
MetaDefender Endpoint™ wurde eingesetzt, um dieses CVE proaktiv zu entschärfen, indem es seine "Vulnerable Application"-Funktion nutzt. Die Lösung lokalisiert und zeigt alle zugehörigen CVEs für Google Chrome-Anwendungen innerhalb der Endpunktumgebung an. Um die Bedrohung zu neutralisieren, können Benutzer Chrome sofort deinstallieren oder den neuesten Sicherheitspatch anwenden. Durch die Implementierung einer der beiden Gegenmaßnahmen wird die CVE vollständig eingedämmt, wodurch das Risiko eines erfolgreichen Cyberangriffs auf den Endpunkt erheblich verringert wird.
Endpoint der nächsten Stufe
Entdecken Sie, warum Organisationen, Institutionen und Unternehmen auf der ganzen Welt beim Schutz kritischer Endpunkte auf MetaDefender Endpoint vertrauen. Sprechen Sie noch heute mit einem Experten, um mehr zu erfahren, und überzeugen Sie sich selbst in einer kostenlosen Demo.
Referenzen
https://nvd.nist.gov/vuln/detail/CVE-2024-0517
https://cwe.mitre.org/data/definitions/843.html
https://blog.exodusintel.com/2024/01/19/google-chrome-v8-cve-2024-0517-out-of-bounds-write-code-execution/
https://jhalon.github.io/chrome-browser-exploitation-1/
https://whenderson.dev/blog/webgl-garbage-collection/
https://v8.dev/
https://github.com/Uniguri/CVE-nday/tree/master/Chrome/V8/CVE-2024-0517
