Patched GIF Processing Vulnerability CVE-2019-11932 Still Afflicts Multiple Mobile Apps

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, 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.

Technical details

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 is decompiled:

Figure 1. Source code for memory allocation during frame retrieval

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.

Figure 2. Definition of reallocarray function

The realloc function and some other checks form the function reallocarray.

Figure 3. Direct call of realloc

If a2 is 0, then the function realloc is directly called. Looking for its definition, we can see that:

Figure 4. Definiton of realloc

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.

Figure 5. Test code and results

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).

Figure 6. Debug results of crashing app

Figure 7. Crash message of app

The latest version of 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.

Figure 8. Bin diff results

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.

Figure 9. Patched source code

Vulnerability Impact

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.

Figure 10. Number of vulnerable apps

We took a closer look at some of these applications to verify that they were indeed vulnerable. We extracted the libraries and found that was not updated, confirming that the vulnerability was present.

We analyzed the 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:

  • F613296C6076DF86671D1B51739A23802169541B1057D40B2C61BF583032C9F9

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.

Figure 11. Code showing that the vulnerable app does not check the size before the reallocarray function is called

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 if they are using it to reduce the risk to end users.

The post Patched GIF Processing Vulnerability CVE-2019-11932 Still Afflicts Multiple Mobile Apps appeared first on .

This post appeared first on Trend Macro Blog
Author: Trend Micro