End Date: Thursday Dec-26-2019 1:20:54 PST
Buy It Now for only: $19.99
Buy It Now | Add to watch list
End Date: Thursday Dec-19-2019 4:23:43 PST
Buy It Now for only: $6.99
Buy It Now | Add to watch list
By Lance Jiang and Jesse Chang
CVE-2019-11932, which is a vulnerability in WhatsApp for Android, was first disclosed to the public on October 2, 2019 after a researcher named Awakened discovered that attackers could use maliciously crafted GIF files to allow remote code execution. The vulnerability was patched with version 2.19.244 of WhatsApp, but the underlying problem lies in the library called libpl_droidsonroids_gif.so, which is part of the android-gif-drawable package. While this flaw has also been patched, many applications still use the older version and remain at risk.
A GIF file will be resolved by the allocation of GifInfo *info, and then the stored frames are read one by one. Every frame will use the info->rasterBits pointer and call reallocarray(info->rasterBits,size,), and realloc will succeed and the info->rasterBits pointer will be flushed if size is not 0. However, if size is 0, realloc will fail, the info->rasterBits pointer will not be flushed, and it will be free. For example, when we get the first frame, the size is not 0, we get a new info->rasterBits pointer. If the next two frame sizes are both 0, the reallocarry() function will free the same info->rasterBits pointer twice, which could lead to a double-free vulnerability. The issue code can be found when libpl_droidsonroids_gif.so is decompiled:
The variable v25 represents v24*v23, which is the frame’s width and height. However, it never checks whether the value is zero. When the result is 0, then it breaks and returns; otherwise it will give its value to v3+88, which could be the first argument the next time reallocarray is called.
The realloc function and some other checks form the function reallocarray.
If a2 is 0, then the function realloc is directly called. Looking for its definition, we can see that:
On Android, if there is a double free of a memory location, then calling malloc with the same size twice will return the same address. I then wrote one sample to verify this. Below is the simple form of this vulnerability and following exploit.
Here, a1 and a2 can reuse the same address. Similarly, when the gallery inside WhatsApp is opened, the GIF file will be parsed and shown twice because of the gallery’s properties. This means that GifInfo will be allocated twice.
If the GIF file has three frames, the first frame’s width and height must not be zero, and next two frames are 0. Here, a double free will occur in the first display and next picture will be shown twice. GifInfo will be reallocated, and each such subsequent allocation will reuse the same freed address. The first frame will overwrite the GifInfo structure, allowing us to control the PC pointer if we give some ROP gadget address in the location of GifInfo->rewindFunction.
The GifInfo->rewindFunction pointer is overwritten when the GifInfo structure is parsed for the second time, and causes arbitrary execution of the code in the specified. We found two apps on Google Play with millions of downloads and parsed the PoC code. They crashed (debug results below).
The latest version of libpl_droidsonroids_gif.so has fixed the vulnerability, as we can see from the bin diff results below: the left is Whatsapp 2.19.216, and the right is Whatsapp 2.19.291. It checks the second argument passed into reallocarray.
The patched version added built-in checks; if width*height is 0, the free function is called and let v9 equal null; v9 here is represented by info->rasterBits.
The video below demonstrates the vulnerability. On the left is the target device, and the right is a system representing the attacker. We have previously generated a malicious GIF, and this is then sent to the target device. When the victim receives and opens the Gallery, the vulnerability can be triggered and returns the content of /system/etc/hosts on the phone. We can return the content of any file what we want, and we can return a shell to gain control of the phone.
Figure 10. Demonstration of this vulnerability
Our analysis of this threat led us to ask: how many applications still had this vulnerable library? As it turned out, quite a few. On Google Play alone, we found more than 3,000 applications with this vulnerability. We also found many other similar apps hosted on third-party app stores such as 1mobile, 9Apps, 91 market, APKPure, Aptoide, 360 Market, PP Assistant, QQ Market, and Xiaomi Market.
We took a closer look at some of these applications to verify that they were indeed vulnerable. We extracted the libraries and found that libpl_droidsonroids_gif.so was not updated, confirming that the vulnerability was present.
We analyzed the libpl_droidsonroids_gif.so in one of these vulnerable apps, and found that it does use the vulnerable version without security updates. We used IDA Pro to extract the vulnerable library, which has the following SHA256 hash:
We then examined the code and found that the vulnerability is still present. As shown below, the size is not checked before the reallocarray function is called. If the app handles a GIF that has three frames with sizes of 0, it will still cause a double free vulnerability.
Best Practices and Solutions
Even though CVE-2019-11932 has been disclosed and patched, there are still a large number of applications that contain the vulnerability, which exposes many Android users to risk. If you accidentally install a vulnerable application, you will be at risk, as an attacker may be able to exploit this vulnerability to take control of this device. We urge developers to upgrade libpl_droidsonroids_gif.so if they are using it to reduce the risk to end users.
Post edited at 7:45 PM Eastern Time to add video demonstrating vulnerability.
The post Patched GIF Processing Vulnerability CVE-2019-11932 Still Afflicts Multiple Mobile Apps appeared first on .