infiniteloopers/cve-2019-11932Informe técnico y código de exploit para CVE-2019-11932, una vulnerabilidad de doble liberación en WhatsApp para Android que conduce a la ejecución remota de código mediante un archivo GIF manipulado.
Voy a compartir una vulnerabilidad de doble liberación que descubrí en WhatsApp para Android, y cómo la convertí en un RCE. Informé de esto a Facebook. Facebook lo reconoció y lo parcheó oficialmente en la versión 2.19.244 de WhatsApp. Facebook ayudó a reservar CVE-2019-11932 para este problema.
Usuarios de WhatsApp, por favor actualicen a la última versión de WhatsApp (2.19.244 o superior) para mantenerse a salvo de este fallo.
Los pasos son los siguientes:
Una de ellas podría ser como Documento a través de WhatsApp (es decir, presionando el botón del clip y eligiendo Documento para enviar el GIF corrupto). Si el atacante está en la lista de contactos del usuario (es decir, es un amigo), el GIF corrupto se descarga automáticamente sin ninguna interacción del usuario.
Tenga en cuenta que el usuario no tiene que enviar nada, porque con solo abrir la Galería de WhatsApp se desencadena el fallo. No es necesario tocar nada más después de presionar la Galería de WhatsApp.
Cuando un usuario de WhatsApp abre la vista de Galería en WhatsApp para enviar un archivo multimedia, WhatsApp lo parsea con una biblioteca nativa llamada libpl_droidsonroids_gif.so para generar la vista previa del archivo GIF. libpl_droidsonroids_gif.so es una biblioteca de código abierto cuyo código fuente está disponible en https://github.com/koral–/android-gif-drawable/tree/dev/android-gif-drawable/src/main/c.
Un archivo GIF contiene múltiples fotogramas codificados. Para almacenar los fotogramas decodificados, se utiliza un búfer llamado rasterBits. Si todos los fotogramas tienen el mismo tamaño, rasterBits se reutiliza para almacenar los fotogramas decodificados sin reasignación. Sin embargo, rasterBits se reasignaría si se cumple una de las tres condiciones siguientes:
La reasignación es una combinación de free y malloc. Si el tamaño de la reasignación es 0, simplemente es un free. Supongamos que tenemos un archivo GIF que contiene 3 fotogramas con tamaños de 100, 0 y 0.
Esto da como resultado una vulnerabilidad de doble liberación. El punto de activación se puede encontrar en 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; }
En Android, una doble liberación de una memoria de tamaño N hace que dos asignaciones de memoria posteriores de tamaño N devuelvan la misma dirección.
(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
Cómo un fallo de doble liberación en WhatsApp se convierte en RCE 14 minutos de lectura EN ESTA PÁGINA DEMO VULNERABILIDAD DE DOBLE LIBERACIÓN EN DDGIFSLURP EN DECODING.C EN LIBPL_DROIDSONROIDS_GIF CONTROL DEL REGISTRO PC LIDIAR CON ASLR Y W^X UNIENDO TODO VERSIONES AFECTADAS VECTORES DE ATAQUE In this blog post, I’m going to share about a double-free vulnerability that I discovered in WhatsApp for Android, and how I turned it into an RCE. I informed this to Facebook. Facebook acknowledged and patched it officially in WhatsApp version 2.19.244. Facebook helped to reserve CVE-2019-11932 for this issue.
WhatsApp users, please do update to latest WhatsApp version (2.19.244 or above) to stay safe from this bug.
Demo https://drive.google.com/file/d/1T-v5XG8yQuiPojeMpOAG6UGr2TYpocIj/view
Google Drive link to download if the above link is not accessible https://drive.google.com/open?id=1X9nBlf5oj5ef2UoYGOfusjxAiow8nKEK
Los pasos son los siguientes:
0:16 El atacante envía un archivo GIF al usuario a través de cualquier canal Una de ellas podría ser como Documento a través de WhatsApp (es decir, presionando el botón del clip y eligiendo Documento para enviar el GIF corrupto). Si el atacante está en la lista de contactos del usuario (es decir, es un amigo), el GIF corrupto se descarga automáticamente sin ninguna interacción del usuario. 0:24 El usuario quiere enviar un archivo multimedia a cualquiera de sus amigos de WhatsApp. Entonces presiona el botón del clip y abre la Galería de WhatsApp para elegir un archivo multimedia que enviar a su amigo. Tenga en cuenta que el usuario no tiene que enviar nada, porque con solo abrir la Galería de WhatsApp se desencadena el fallo. No es necesario tocar nada más después de presionar la Galería de WhatsApp. 0:30 Como WhatsApp muestra vistas previas de cada archivo multimedia (incluido el GIF recibido), se desencadenará el fallo de doble liberación y nuestro exploit de RCE. Vulnerabilidad de doble liberación en DDGifSlurp en decoding.c en libpl_droidsonroids_gif Cuando un usuario de WhatsApp abre la vista de Galería en WhatsApp para enviar un archivo multimedia, WhatsApp lo parsea con una biblioteca nativa llamada libpl_droidsonroids_gif.so para generar la vista previa del archivo GIF. libpl_droidsonroids_gif.so es una biblioteca de código abierto cuyo código fuente está disponible en https://github.com/koral–/android-gif-drawable/tree/dev/android-gif-drawable/src/main/c.
Un archivo GIF contiene múltiples fotogramas codificados. Para almacenar los fotogramas decodificados, se utiliza un búfer llamado rasterBits. Si todos los fotogramas tienen el mismo tamaño, rasterBits se reutiliza para almacenar los fotogramas decodificados sin reasignación. Sin embargo, rasterBits se reasignaría si se cumple una de las tres condiciones siguientes:
La reasignación es una combinación de free y malloc. Si el tamaño de la reasignación es 0, simplemente es un free. Supongamos que tenemos un archivo GIF que contiene 3 fotogramas con tamaños de 100, 0 y 0.
Esto da como resultado una vulnerabilidad de doble liberación. El punto de activación se puede encontrar en decoding.c:
