infiniteloopers/cve-2019-11932Analyse technique et code d'exploitation pour CVE-2019-11932, une vulnérabilité de double libération dans WhatsApp pour Android qui mène à une exécution de code à distance via un fichier GIF malveillant.
Je vais partager une vulnérabilité de double libération (double-free) que j'ai découverte dans WhatsApp pour Android, et comment je l'ai transformée en RCE. J'en ai informé Facebook. Facebook a reconnu la faille et l'a corrigée officiellement dans WhatsApp version 2.19.244. Facebook a aidé à réserver le CVE-2019-11932 pour ce problème.
Utilisateurs de WhatsApp, veuillez mettre à jour vers la dernière version de WhatsApp (2.19.244 ou ultérieure) pour rester protégés de ce bug.
Les étapes sont les suivantes :
L'un d'eux pourrait être en tant que Document via WhatsApp (c'est-à-dire en appuyant sur le bouton Trombone et en choisissant Document pour envoyer le GIF corrompu) Si l'attaquant fait partie de la liste de contacts de l'utilisateur (c'est-à-dire un ami), le GIF corrompu est téléchargé automatiquement sans aucune interaction de l'utilisateur.
Notez que l'utilisateur n'a rien à envoyer car le simple fait d'ouvrir la Galerie WhatsApp déclenche le bug. Aucun toucher supplémentaire après avoir appuyé sur Galerie WhatsApp n'est nécessaire.
Lorsqu'un utilisateur WhatsApp ouvre la vue Galerie dans WhatsApp pour envoyer un fichier multimédia, WhatsApp l'analyse avec une bibliothèque native appelée libpl_droidsonroids_gif.so pour générer l'aperçu du fichier GIF. libpl_droidsonroids_gif.so est une bibliothèque open source dont les codes sources sont disponibles sur https://github.com/koral–/android-gif-drawable/tree/dev/android-gif-drawable/src/main/c.
Un fichier GIF contient plusieurs images encodées. Pour stocker les images décodées, un tampon nommé rasterBits est utilisé. Si toutes les images ont la même taille, rasterBits est réutilisé pour stocker les images décodées sans réallocation. Cependant, rasterBits serait réalloué si l'une des trois conditions ci-dessous est remplie :
La réallocation est une combinaison de free et malloc. Si la taille de la réallocation est 0, c'est simplement un free. Disons que nous avons un fichier GIF qui contient 3 images avec des tailles de 100, 0 et 0.
Cela résulte en une vulnérabilité de double libération. L'emplacement de déclenchement se trouve dans 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; }
Comment un bug de double libération dans WhatsApp devient une RCE Lecture de 14 minutes SUR CETTE PAGE DÉMO VULNÉRABILITÉ DE DOUBLE LIBÉRATION DANS DDGIFSLURP DANS DECODING.C DANS LIBPL_DROIDSONROIDS_GIF CONTRÔLE DU REGISTRE PC GÉRER ASLR ET W^X TOUT METTRE ENSEMBLE VERSIONS AFFECTÉES VECTEURS D'ATTAQUE Dans cet article de blog, je vais partager une vulnérabilité de double libération que j'ai découverte dans WhatsApp pour Android, et comment je l'ai transformée en RCE. J'en ai informé Facebook. Facebook a reconnu la faille et l'a corrigée officiellement dans WhatsApp version 2.19.244. Facebook a aidé à réserver le CVE-2019-11932 pour ce problème.
Utilisateurs de WhatsApp, veuillez mettre à jour vers la dernière version de WhatsApp (2.19.244 ou ultérieure) pour rester protégés de ce bug.
Démo https://drive.google.com/file/d/1T-v5XG8yQuiPojeMpOAG6UGr2TYpocIj/view
Lien Google Drive pour télécharger si le lien ci-dessus n'est pas accessible https://drive.google.com/open?id=1X9nBlf5oj5ef2UoYGOfusjxAiow8nKEK
Les étapes sont les suivantes :
0:16 L'attaquant envoie un fichier GIF à l'utilisateur via n'importe quel canal L'un d'eux pourrait être en tant que Document via WhatsApp (c'est-à-dire en appuyant sur le bouton Trombone et en choisissant Document pour envoyer le GIF corrompu) Si l'attaquant fait partie de la liste de contacts de l'utilisateur (c'est-à-dire un ami), le GIF corrompu est téléchargé automatiquement sans aucune interaction de l'utilisateur. 0:24 L'utilisateur veut envoyer un fichier multimédia à l'un de ses amis WhatsApp. Il appuie donc sur le bouton Trombone et ouvre la Galerie WhatsApp pour choisir un fichier multimédia à envoyer à son ami. Notez que l'utilisateur n'a rien à envoyer car le simple fait d'ouvrir la Galerie WhatsApp déclenche le bug. Aucun toucher supplémentaire après avoir appuyé sur Galerie WhatsApp n'est nécessaire. 0:30 Comme WhatsApp affiche des aperçus de chaque média (y compris le fichier GIF reçu), cela déclenche le bug de double libération et notre exploit RCE. Vulnérabilité de double libération dans DDGifSlurp dans decoding.c dans libpl_droidsonroids_gif Lorsqu'un utilisateur WhatsApp ouvre la vue Galerie dans WhatsApp pour envoyer un fichier multimédia, WhatsApp l'analyse avec une bibliothèque native appelée libpl_droidsonroids_gif.so pour générer l'aperçu du fichier GIF. libpl_droidsonroids_gif.so est une bibliothèque open source dont les codes sources sont disponibles sur https://github.com/koral–/android-gif-drawable/tree/dev/android-gif-drawable/src/main/c.
Un fichier GIF contient plusieurs images encodées. Pour stocker les images décodées, un tampon nommé rasterBits est utilisé. Si toutes les images ont la même taille, rasterBits est réutilisé pour stocker les images décodées sans réallocation. Cependant, rasterBits serait réalloué si l'une des trois conditions ci-dessous est remplie :
width * height > originalWidth * originalHeight width - originalWidth > 0 height - originalHeight > 0 La réallocation est une combinaison de free et malloc. Si la taille de la réallocation est 0, c'est simplement un free. Disons que nous avons un fichier GIF qui contient 3 images avec des tailles de 100, 0 et 0.
Après la première réallocation, nous avons un tampon info->rasterBits de taille 100. Dans la deuxième réallocation de 0, le tampon info->rasterBits est libéré. Dans la troisième réallocation de 0, info->rasterBits est libéré à nouveau. Cela résulte en une vulnérabilité de double libération. L'emplacement de déclenchement se trouve dans decoding.c :
