Microsoft boosts Internet Explorer immunity to use-after-free attacks

In our post on ASLR improvements in recent versions of Windows, a table with a list of Remote Code Execution vulnerabilities that attackers used to remotely install malicious code into the system (drive-by download) was provided. More than half of these vulnerabilities are type t. use-after-free (UAF). UAF can be described as a convenient way for attackers to transfer control to their code. In such a scheme, a legitimate executable code, such as the Internet Explorer browser, must contain incorrect logic for working with memory, which is that at some stage the code fragment accesses a pointer to that heap memory block that was already released earlier.



Obviously, such an error when working with memory can simply cause a crash of the browser, since it will be accessed by an invalid pointer. However, in the case of an exploit, attackers use it for their own purposes in such a way as to force the vulnerable code to transfer control to the correct address. As a rule, heap-spray is used for this, which contributes to reserving a large number of memory blocks at a predictable address on the heap with filling them with necessary instructions to the attacker. In the June and July cumulative updates for the Internet Explorer 11 browser, Microsoft introduced additional mitigation technologies in the form of an isolated heap when allocating memory for objects and deferred release of memory blocks. This approach will protect the browser code, which still may contain errors when working with memory, from the actions of exploits.

Usually the logic of working with heap memory is as follows:
')
1) the browser allocates a block of memory in the heap;
2) uses it;
3) releases.

In the case of a bug in the code, working with memory can be:

1) the browser allocates a block of memory in the heap;
2) uses it;
3) releases;
4) repeatedly refers to this block by the pointer stored in the variable (for example, via vtable).

The most common mock exploitation might look like this:

1) the browser allocates a block of memory in the heap;
2) uses it;
3) releases;
4) the user visits the web page with the exploit;
5) the exploit performs spray heaps (for ASLR bypass) and fills the blocks with the necessary code (for example, shell code) or memory addresses (for the vulnerability to trigger);
6) the exploit creates conditions for the situation of the browser code addressing by an invalid pointer, which is already valid, as clause 4;
7) the browser re-accesses the pointer and transfers control to the memory block with unauthorized code (before this, run the exploit gadgets that disable DEP for the heap blocks via ntdll! NtProtectVirtualMemory ).

In such a situation, to protect the vulnerable code from exploitation, a separate heap of memory can be used and the delayed release of memory from it. Since the memory block will be released later, attackers will not be able to re-reserve this address. Such a mechanism was introduced by Microsoft.


Fig. Isolated heap memory allocation using the CMarkup :: CreateInitialMarkup method to initialize a CMarkup object, see Microsoft Internet Explorer CMarkup Use-After-Free Remote Code Execution Vulnerability . Before MS14-035, the allocation was made from a common heap of process memory.


Fig. July MS14-037 introduced a deferred release of memory blocks by the MemoryProtection :: CMemoryProtector :: ProtectedFree method, which does not perform the actual release of the block, but simply marks the necessary notes about it in the system data structure.


Fig. Methods that are responsible for implementing the deferred-release logic.


Fig. The MemoryProtection :: CMemoryProtector :: ProtectedFree method introduces deferred release of memory blocks of the isolated heap _g_hIsolatedHeap and the heap of the _g_hProcessHeap process itself .


Fig. Delayed memory release is also used by the CTreeNode class, see previous use of use-after-free CVE-2013-3893.

Thus, when working on up-to-date versions of Windows 8.1 x64 with Internet Explorer 11, the user has the necessary capabilities to prevent the exploitation of 0day vulnerabilities.




be secure.