Mitigating UAF Exploits with Delay Free for Internet Explorer

After introducing the “isolated heap” in June security patch for Internet Explorer, Microsoft has once again introduced several improvements in the July patch for Internet Explorer. The most interesting and smart improvement is one which we will call “delay free.” This improvement is designed to mitigate Use After Free (UAF) vulnerability exploits by making sure Internet Explorer does not free object‘s heap space immediately when its reference count is zero.

Take Internet Explorer 11, for example. We randomly selected the class CDivElement. Before the latest Microsoft patch, the class’s operator delete function deletes the object’s heap space immediately. The previous code was as follows:

Figure 1. Previous code

After the latest patch rollout, the code has been changed to the following:

Figure 2. New code

It calls the function MemoryProtection::CMemoryProtector::ProtectedFree. The function is newly introduced in this patch. In the function , we can see that it saves the object address and length to an array which is a member of CMemoryProtector. The CMemoryProtector instance address is recorded in the thread local storage. Thus, the object heap space doesn’t have to be freed and later codes in the same thread can still access the object heap space.

When is the object space freed? It happens at two points:

In the beginning of MSHTML!GlobalWndProc, it will call CMemoryProtector::ProtectCurrentThread. The function will call CMemoryProtector::ReclaimMemoryWithoutProtection to really free the all items in the array which is saved in this thread local storage.

Figure 3. Call Stack
When an object deletes and calls CMemoryProtector::ProtectedFree and if the total hold waiting delay free objects size is over a threshold, it will start free process.

How can the “delay free” mitigate UAF vulnerability exploits?

In a typical UAF exploit, it begins when an object’s heap space is freed. With the “delay free” improvement, attackers will find it difficult to find a timing to occupy the freed object space. As previously mentioned, the current free space timing is located in the MSHTML!GlobalWndProc. If attackers want to occupy the freed object space, they must do it after MSHTML!GlobalWndProc. This function is called when a window or application-defined message is coming. If attackers call alert in JavaScript, it will lead IE to call MSHTML!GlobalWndProc. After this, attackers can write spray heap code to occupy object memory space. I explained the possible attack scenarios in my previous blog entry about isolated heap.

Will this attack succeed? No, it will not. This is because this call to MSHTML!GlobalWndProc will not really free the object space every time. From the code, we can see that before it frees the space, it will check the current stack location to prevent this condition. Internet Explorer makes sure the object space is freed after the JavaScript execution is over.

Google Chrome has implementation that does memory protection to mitigate exploits. It divides the heap in several partitions. The object is allocated in the corresponding partition. For example, DOM node objects are allocated in a specific partition and Array buffer objects are allocated to another partition. This part can be taken as the corresponding section of “isolate heap.” However, there doesn’t seem to be corresponding section for “delay free.”

While other types of vulnerabilities exploits (such as type confusion) aren’t addressed by this improvement, we are pleased to see the continuous efforts of Microsoft to address UAF exploits. This new improvement, coupled with the isolated heap, will make it more difficult for attackers to exploit UAF vulnerabilities.

Post from: Trendlabs Security Intelligence Blog – by Trend Micro

Mitigating UAF Exploits with Delay Free for Internet Explorer