Microsoft strengthens Internet Explorer's immunity to use-after-free attacks

    Our post on ASLR enhancements in recent versions of Windows provided a table listing the Remote Code Execution vulnerabilities that attackers used to remotely install malicious code into the system (drive-by download). More than half of these vulnerabilities are of the so-called type. use-after-free (UAF). UAF can be described as a convenient way for attackers to transfer control to their code. In such a scheme, legitimate executable code, for example, Internet Explorer, must contain incorrect logic for working with memory, which consists in the fact that at some stage a piece of code accesses a pointer to that block of memory in the heap that has already been freed up earlier.



    Obviously, such an error when working with memory can simply cause the browser to crash, because it will be accessed by an invalid pointer. However, in the case of the exploit, attackers use it for their own purposes in such a way as to force the vulnerable code to transfer control to the desired address. As a rule, heap-spray is used for this, which helps to reserve a large number of memory blocks at a predictable address in the heap with filling them with instructions necessary for the attacker. In June and Julycumulative updates for Internet Explorer 11, Microsoft has 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 may still contain errors when working with memory, from the actions of exploits.

    Typically, the logic for working with heap memory is as follows:

    1) the browser allocates a block of memory on the heap;
    2) uses it;
    3) releases.

    In the case of a bug in the code, working with memory may look like:

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

    The most common exploitation layout may look like this:

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

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


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


    Fig. July MS14-037 introduced delayed release of memory blocks using MemoryProtection :: CMemoryProtector :: ProtectedFree, which does not actually release the block, but simply marks the necessary notes about it in the system data structure.


    Fig. Methods that are responsible for implementing deferred memory logic.


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


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

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



    image
    be secure.

    Also popular now: