gkrishnan724/cve-2021-38297Ein Proof-of-Concept-Szenario zur Ausnutzung von CVE2021-38297 GO WASM Buffer-Overflow
WebAssembly (WASM) dient als binäres Befehlsformat, das in den meisten modernen Webbrowsern ausführbar ist. Es fungiert als Kompilierungsziel für verschiedene höhere Sprachen wie C, C++, Rust und GO und ermöglicht es, Code in diesen Sprachen zu schreiben und in WASM zu kompilieren.
CVE-2021-38297 hebt einen kritischen Fehler in GOs Kompilierung und Laden von GO-kompilierten WASM-Binärdateien hervor. Die Schwachstelle befindet sich im JS-Wasm-Loader (wasm_exec.js) von GO, der das Laden von WASM-Binärdateien mit uneingeschränkten Daten im argv-Argument ermöglicht. Da argv im linearen Speicher von WASM gespeichert wird, könnten böswillige Akteure dies ausnutzen, um den linearen Speicher des GO-kompilierten WASM-Programms mit einer übermäßig großen argv-Eingabe zu überschreiben.
Diese Schwachstelle bestand in GO-Versionen vor 1.17.2.
Dieser Proof of Concept stellt eine Social-Media-Anwendung namens Vuln-Twitter vor, die mehreren Benutzern ermöglicht, Beiträge und Kommentare zu veröffentlichen. Der auf Node.js basierende Webserver verwendet SQLite zum Speichern von Beitrags- und Kommentardaten.
Das Frontend verwendet einfaches JS zusammen mit einem GO WASM-Modul namens wordprocessor.wasm. Dieses Modul stellt Methoden wie toLeetSpeak bereit, die Eingabezeichenfolgen in „LeetSpeak" umwandeln (z. B. wird aus „Hello!" „h3ll0!").
Die GO WASM-Module helfen bei der Darstellung von Beiträgen und Kommentaren in LeetSpeak.
Während des Frontend-Renderings, wenn Beiträge und Kommentare vom Server empfangen werden, wird jeder Kommentar mit dem GO WASM-Modul in „LeetSpeak" umgewandelt. Der Kommentar für jeden Beitrag wird als Teil der argv-Variable nach dem Laden des GO WASM-Moduls übergeben.
Darüber hinaus gibt es eine Methode processSharedVar() im GO-Modul, die dazu dient, die Zeichenfolge an der Adresse 0x5000 zu lesen und in vereinfachte Sprache umzuwandeln (z. B. wird aus „How are you?" „How r u?"). Der ursprüngliche Beitrag wird explizit an 0x5000 im linearen Speicher hinzugefügt, um von dieser Methode abgerufen zu werden, wodurch der Beitragsinhalt geändert wird.
Siehe den entsprechenden Codeabschnitt:
WASM Linear Memory Diagramm beim Rendern eines Kommentars:
Zusammenfassung:
argv-Variable und Beiträge an der Speicheradresse 0x5000 verarbeitet.toLeetSpeak und processSharedVar werden für Kommentar- bzw. Beitragsinhalte verwendet.Angesichts des Fehlens von Größenprüfungen in argv basierend auf CVE-2021-38297 ergibt sich eine potenzielle Bedrohung. Wenn ein böswilliger Benutzer einen übermäßig großen Kommentar zu einem Beitrag hinterlässt, den er nicht besitzt, wird dieser Kommentar während des Renderns über argv übergeben. Da es keine Größenbeschränkung gibt, wird der Inhalt an Adresse 0x5000 (der den ursprünglichen Beitrag darstellt) anfällig für Überschreiben.
Durch Ausnutzung dieses Fehlers kann ein böswilliger Benutzer den ursprünglichen Beitragsinhalt effektiv verändern, ähnlich wie bei einem Stored-XSS-Angriff. In der Folge wird beim Betrachten der Seite durch andere der veränderte Inhalt angezeigt, verstärkt durch die gemeinsame Frontend-Logik, die auf das Rendering aller angewendet wird, sodass der überschriebene Beitrag für alle sichtbar ist.
Hinweis: Zur Reproduktion müssen Sie lokal die Go-Version go1.17.1 installieren, die in diesem Szenario die anfällige Version ist. Sie können die offizielle Go-Dokumentation zur Installation bestimmter Go-Versionen konsultieren.
Versuchen wir nun, das obige Szenario zu reproduzieren:
git clone [email protected]:gkrishnan724/CVE-2021-38297.git && cd vuln-twitternpm install aus, um alle Abhängigkeiten zu installieren.npm run resetDB aus, was die Datenbank mit einigen Beiträgen und Kommentaren initialisiert.npm run dev aus, was den lokalen Server startet; öffnen Sie localhost:3000 in einem Browser, und Sie sollten eine Anmeldeseite sehen.Melden Sie sich nun mit einem böswilligen Konto an, verwenden Sie die Anmeldedaten Benutzername: I_CANT_HACK, Passwort: hacker. Nach der Anmeldung sollten Sie den Feed mit einigen Beiträgen sehen.
Dieser Beitrag scheint ziemlich interessant:
Amazon: ready 4 black friday? https://www.amazon.com/blackfriday
Was wäre, wenn wir mit der obigen Technik den Beitrag von Amazon.com überschreiben könnten, um auf einen bösartigen Link zu verweisen?
Siehe die Datei exploit.txt, die den Kommentar enthält, der mit einer Polsterung von „A"s gefüllt ist, sodass wir alles bis zur Adresse 0x5000 überschreiben. Am Ende sehen Sie den Text ready for black friday? https://evil.com/blackfriday. Wenn wir diesen Text kopieren und auf den obigen Beitrag kommentieren, sollten wir den ursprünglichen Beitrag mit dem obigen Text überschreiben können.
Probieren Sie es selbst aus und sehen Sie :)
In dieser Anwendung habe ich auch ein Patch-Skript bereitgestellt, das eine neuere Version von Go verwendet:
npm run patchServer ausDies sollte die Go-Datei mit der neuen Version neu kompilieren und den Server mit der Patch-Version starten.
Sie sollten nun feststellen, dass der Beitrag nicht überschrieben wird. Wenn Sie die Konsole beobachten, sehen Sie stattdessen einen Fehler: Argument length too long.
Wir haben ein Szenario demonstriert, in dem die Ausnutzung eines WASM-Pufferüberlaufs im linearen Speicher es uns ermöglichte, einen Stored-XSS-Angriff durchzuführen. Es ist jedoch wichtig, die Spezifität dieses Exploits zu beachten: Es erforderte, dass wir einen Text an einer fest codierten Adresse im linearen Speicher manipulieren. In praktischen Webanwendungen kann die Entdeckung solcher Schwachstellen aufgrund dieser Spezifität äußerst schwierig sein. Darüber hinaus ist das Überschreiben beliebiger Daten im linearen Speicher, ohne einen Systemabsturz zu verursachen, kompliziert, insbesondere bei der Arbeit mit Go-internen Modulen und Daten, was vor allem auf das Fehlen einer umfassenden Dokumentation des Go-Speicherlayouts zurückzuführen ist.
Basierend auf unserem Verständnis glauben wir, dass das lineare Go-Speicherlayout unten dargestellt ist:
