infiniteloopers/cve-2019-11932Technischer Bericht und Exploit-Code für CVE-2019-11932, eine Double-Free-Schwachstelle in WhatsApp für Android, die zu Remote-Codeausführung über eine manipulierte GIF-Datei führt.
Ich werde über eine Double-Free-Sicherheitslücke berichten, die ich in WhatsApp für Android entdeckt habe, und wie ich sie in eine RCE umgewandelt habe. Ich habe dies Facebook gemeldet. Facebook hat den Fehler bestätigt und offiziell in WhatsApp Version 2.19.244 behoben. Facebook half dabei, CVE-2019-11932 für dieses Problem zu reservieren.
WhatsApp-Nutzer, bitte aktualisiert auf die neueste WhatsApp-Version (2.19.244 oder höher), um vor diesem Bug geschützt zu sein.
Die Schritte sind wie folgt:
Eine Möglichkeit ist als Dokument über WhatsApp (d.h. den Büroklammer-Button drücken und Dokument auswählen, um das manipulierte GIF zu senden) Wenn sich der Angreifer in der Kontaktliste des Benutzers befindet (d.h. ein Freund), wird das manipulierte GIF automatisch ohne Benutzerinteraktion heruntergeladen.
Beachten Sie, dass der Benutzer nichts senden muss, da bereits das Öffnen der WhatsApp-Galerie den Bug auslöst. Nach dem Drücken der WhatsApp-Galerie ist keine weitere Berührung erforderlich.
Wenn ein WhatsApp-Benutzer die Galerieansicht in WhatsApp öffnet, um eine Mediendatei zu senden, parst WhatsApp diese mit einer nativen Bibliothek namens libpl_droidsonroids_gif.so, um die Vorschau der GIF-Datei zu generieren. libpl_droidsonroids_gif.so ist eine Open-Source-Bibliothek mit Quellcode verfügbar unter https://github.com/koral–/android-gif-drawable/tree/dev/android-gif-drawable/src/main/c.
Eine GIF-Datei enthält mehrere codierte Frames. Zum Speichern der decodierten Frames wird ein Puffer mit dem Namen rasterBits verwendet. Wenn alle Frames die gleiche Größe haben, wird rasterBits ohne Neuzuweisung wiederverwendet, um die decodierten Frames zu speichern. Allerdings wird rasterBits neu zugewiesen, wenn eine der folgenden drei Bedingungen erfüllt ist:
Neuzuweisung ist eine Kombination aus free und malloc. Wenn die Größe der Neuzuweisung 0 ist, handelt es sich lediglich um einen free. Angenommen, wir haben eine GIF-Datei, die 3 Frames mit den Größen 100, 0 und 0 enthält.
Dies führt zu einer Double-Free-Sicherheitslücke. Die Auslösestelle findet sich in decoding.c:
int_fast32_t widthOverflow = gifFilePtr->Image.Width - info->originalWidth; int_fast32_t heightOverflow = gifFilePtr->Image.Height - info->originalHeight; const uint_fast32_t newRasterSize = gifFilePtr->Image.Width * gifFilePtr->Image.Height; if (newRasterSize > info->rasterSize || widthOverflow > 0 || heightOverflow > 0) { void *tmpRasterBits = reallocarray(info->rasterBits, newRasterSize, <<-- double-free here sizeof(GifPixelType)); if (tmpRasterBits == NULL) { gifFilePtr->Error = D_GIF_ERR_NOT_ENOUGH_MEM; break; } info->rasterBits = tmpRasterBits; info->rasterSize = newRasterSize; }
Wie ein Double-Free-Fehler in WhatsApp zu RCE wird 14 Minuten Lesezeit AUF DIESER SEITE DEMO DOUBLE-FREE-SICHERHEITSLÜCKE IN DDGIFSLURP IN DECODING.C IN LIBPL_DROIDSONROIDS_GIF PC-REGISTER KONTROLLIEREN UMGANG MIT ASLR UND W^X ALLES ZUSAMMENFÜGEN BETROFFENE VERSIONEN ANGRIFFSVEKTOREN In diesem Blogbeitrag werde ich über eine Double-Free-Sicherheitslücke berichten, die ich in WhatsApp für Android entdeckt habe, und wie ich sie in eine RCE umgewandelt habe. Ich habe dies Facebook gemeldet. Facebook hat den Fehler bestätigt und offiziell in WhatsApp Version 2.19.244 behoben. Facebook half dabei, CVE-2019-11932 für dieses Problem zu reservieren.
WhatsApp-Nutzer, bitte aktualisiert auf die neueste WhatsApp-Version (2.19.244 oder höher), um vor diesem Bug geschützt zu sein.
Demo https://drive.google.com/file/d/1T-v5XG8yQuiPojeMpOAG6UGr2TYpocIj/view
Google Drive-Link zum Herunterladen, falls der obige Link nicht zugänglich ist https://drive.google.com/open?id=1X9nBlf5oj5ef2UoYGOfusjxAiow8nKEK
Die Schritte sind wie folgt:
0:16 Angreifer sendet GIF-Datei über beliebige Kanäle an Benutzer Eine Möglichkeit ist als Dokument über WhatsApp (d.h. den Büroklammer-Button drücken und Dokument auswählen, um das manipulierte GIF zu senden) Wenn sich der Angreifer in der Kontaktliste des Benutzers befindet (d.h. ein Freund), wird das manipulierte GIF automatisch ohne Benutzerinteraktion heruntergeladen. 0:24 Benutzer möchte eine Mediendatei an einen seiner WhatsApp-Freunde senden. Der Benutzer drückt daher den Büroklammer-Button und öffnet die WhatsApp-Galerie, um eine Mediendatei zum Senden an seinen Freund auszuwählen. Beachten Sie, dass der Benutzer nichts senden muss, da bereits das Öffnen der WhatsApp-Galerie den Bug auslöst. Nach dem Drücken der WhatsApp-Galerie ist keine weitere Berührung erforderlich. 0:30 Da WhatsApp Vorschaubilder aller Medien anzeigt (einschließlich der empfangenen GIF-Datei), wird der Double-Free-Bug und unser RCE-Exploit ausgelöst. Double-Free-Sicherheitslücke in DDGifSlurp in decoding.c in libpl_droidsonroids_gif Wenn ein WhatsApp-Benutzer die Galerieansicht in WhatsApp öffnet, um eine Mediendatei zu senden, parst WhatsApp diese mit einer nativen Bibliothek namens libpl_droidsonroids_gif.so, um die Vorschau der GIF-Datei zu generieren. libpl_droidsonroids_gif.so ist eine Open-Source-Bibliothek mit Quellcode verfügbar unter https://github.com/koral–/android-gif-drawable/tree/dev/android-gif-drawable/src/main/c.
Eine GIF-Datei enthält mehrere codierte Frames. Zum Speichern der decodierten Frames wird ein Puffer mit dem Namen rasterBits verwendet. Wenn alle Frames die gleiche Größe haben, wird rasterBits ohne Neuzuweisung wiederverwendet, um die decodierten Frames zu speichern. Allerdings wird rasterBits neu zugewiesen, wenn eine der folgenden drei Bedingungen erfüllt ist:
Breite * Höhe > ursprünglicheBreite * ursprünglicheHöhe Breite - ursprünglicheBreite > 0 Höhe - ursprünglicheHöhe > 0 Neuzuweisung ist eine Kombination aus free und malloc. Wenn die Größe der Neuzuweisung 0 ist, handelt es sich lediglich um einen free. Angenommen, wir haben eine GIF-Datei, die 3 Frames mit den Größen 100, 0 und 0 enthält.
Nach der ersten Neuzuweisung haben wir einen info->rasterBits-Puffer der Größe 100. Bei der zweiten Neuzuweisung von 0 wird der info->rasterBits-Puffer freigegeben. Bei der dritten Neuzuweisung von 0 wird info->rasterBits erneut freigegeben. Dies führt zu einer Double-Free-Sicherheitslücke. Die Auslösestelle findet sich in decoding.c:
