Trend Micro Facebook TrendLabs Twitter Malware Blog RSS Feed You Tube - Trend Micro
Search our blog:

  • Recent Posts

  • Calendar

    January 2015
    S M T W T F S
    « Dec    
  • Email Subscription

  • About Us
    TrendLabs Security Intelligence Blog(breadcrumbs are unavailable)

    Author Archive - Jack Tang (Threats Analyst)

    Applications that have been frequently targeted by exploits frequently add sandboxes to their features in order to harden their defenses against these attacks. To carry out a successful exploit, an attacker will have to breach these sandboxes to run malicious code. As a result, researchers will pay particular attention to exploits that are able to escape sandboxes.

    In both October and November Patch Tuesday cycles, Microsoft addressed several vulnerabilities that were used by attackers to escape the Internet Explorer sandbox. One of these was CVE-2014-6349, which was addressed by Microsoft as part of MS14-065, November’s cumulative Internet Explorer patch. We chose this particular vulnerability for two reasons: exploiting it is relatively easy, and its methodology – using shared memory to escape the Internet Explorer sandbox – has not been seen before. A separate vulnerability that also allowed for sandbox escapes – CVE-2014-6350 – was also fixed in the same patch, and Google released details about this second vulnerability earlier this week.

    Internet Explorer 11 exposes a shared memory section object to all tab process (which are sandboxed). This is used to store various Internet Explorer settings. Normally, the tab processes only read this to see these settings. However, in Enhanced Protected Mode (EPM, which is IE’s sandbox mode), the shared memory section‘s DACL (Discretionary Access Control List) is not configured correctly. The tab processes have “write” permission to modify the shared memory section content. This can be used by an attacker to break the IE sandbox. How can this be done? We will explain this in the rest of this post.

    To understand the concepts covered in this post, background knowledge about Protected Mode (PM) and EPM is necessary. These MSDN documents and HITB presentations provide background information on these topics. I carried out my tests on a system running Windows 8.1 with Internet Explorer 11.0.9600.17107.

    After enable IE 11’s EPM mode,  we run IE. The broker process and tab process are seen below:

    Figure 1. Internet Explorer broker and tab processes

    The parent iexplore.exe broker process’s integrity is Medium. The iexplore.exe tab process’s integrity is AppContainer. This means the web page rendering in the sandboxed tab process is in the sandbox and its privilege is controlled. Both process share a memory section: \Sessions\1\BaseNamedObjects\ie_ias_<frame process id>-0000-0000-0000-000000000000.

    Read the rest of this entry »

    Posted in Exploits, Vulnerabilities |

    We see many kinds of vulnerabilities on a regular basis. These range from user-after-free (UAF) vulnerabilities, to type confusion, to buffer overflows, to cross-site scripting (XSS) attacks. It’s rather interesting to understand the root cause of each of these vulnerability types, so we looked at the root cause of an Internet Explorer vulnerability – CVE-2014-1772.

    We’d privately disclosed this vulnerability to Microsoft earlier in the year, and it had been fixed as part of the June Patch Tuesday update, as part of MS14-035. While this vulnerability was already patched some time ago, it is still a good example of UAF vulnerabilities in general.

    The code to trigger this vulnerability is below:

    Figure 1. HTML code to trigger vulnerability

    Before debugging, several flags must be set to make the job of analysis easier. Run the command gflags.exe /i iexplore.exe +hpa +ust to to enable the page heap (HPA) and user stack trace (UST) flags. This will make finding memory corruption and tracing heap allocation and frees easier. This file can be found in the Windbg installation folder. You can now run windbg, attach Internet Explorer, and use it to access the HTML file.

    Examining the JavaScript execution flow, when line 18 of the HTML code is executed, the crash happens:

    Figure 2. Output of crash

    We can see the EDI register point to a freed memory space, which leads to an access violation.

    What is the value of the EDI register? Let us look at the code below.

    Figure 3. Assembly code

    The above code tells us that the EDI is from the first argument, which is the CTreePos* type. We can assume the EDI is a pointer of CTreePos. Since the CTreePos object is freed, how can we get where the object is freed? Because the UST flag is set, we can use the !heap -p -a edi command in windbg.

    Figure 4. Call stack

    The above figure shows us the call stack of the CTreePos object freed. The call stack has a lot of information. We see the function CMarkup::FreeTreePos; this evidence gives us evidence that the freed object is CTreePos object and that this is a use-after-free issue.

    Since it is a UAF issue, we want to deeply understand the issue. We need to locate where the CTreePos object is created, where the object is freed, and where the freed object is used again. Figure 4 gives us where the object was freed. To find where is used again, we need to examine the crash point. The call stack is as follows:

    Figure 5. Call stack

    How do we find the location where the CTreePos object was created? There are many ways. I prefer to run the sample again, and break the object freed point and use the !heap -p -a xxxx command to trace back to where the object is created. The call stack is as follows:

    Figure 6. Call stack

    For UAF problems, I prefer to compare the 3 locations (create, free, use again) to find some clues.

    Figure 7. Call stacks

    There are 3 columns in Figure 7. They are call stack trace summaries: from left to right, it is when the object is created, freed, and used again. In the above example, the direction of the stack is from the bottom to the top.

    There is plenty of useful information here. First, we can find the relationship between the 3 parts. Under the yellow line, CDoc::CutCopyMove is the last identical function in the creation call stack trace and the free call stack trace. This means the execution flow creates the CTreePos object and then frees the object in CDoc::CutCopyMove. Under the red line, the execution flow frees the object and then uses it again (and crashes) in CSpliceTreeEngine::InsertSplice.

    In the second column, we find the execution flow in the CSpliceTreeEngine::InsertSplice function encounters a failure and call the Fire_onerror function. The function will call the JavaScript object’s onerror event. At the event, the execution will call CMarkupPointer::UnEmbed to free the object.

    Right away, we have four questions.

    1. Why does it trigger an onerror event?
    2. Why does it create the CTreePos object?
    3. Why does it free the CTreePos object?
    4. Why does it use the freed object again?

    Before answering these questions, I want to summarize some background knowledge about how Internet Explorer’s DOM tree implementation. Because IE is not open source, this information is gathered by reverse engineering, so it may not be 100% accurate.

    One page has a CMarkup object to represent the page’s skeleton or DOM tree. The CMarkup object contain a pointer to the root CElement object. This is the parent class of many concrete element classes. In Figure 1, the Javascript object e_1 and e_2 are the CObjectElement objects which are inherited from CElement. The CElement object has a pointer to a CTreeNode object. The CTreeNode object also has a pointer to a related CElement object. The CTreeNode’s object has a pair of pointer to CTreePos objects.

    Why is a CTreePos object needed? This is because IE uses a Splay Tree algorithm to manuiplate the DOM tree. In the Splay Tree, the CTreePos object is the node that is involved in the algorithm. The CMarkupPointer object represents a location in the CMarkup object (DOM tree). So the CMarkupPointer object has a pointer to CTreePos to represent its location. CMarkupPointer has several statuses which are related to UAF issues.

    • Embed status: this means CMarkupPointer created CTreePos, which is added to the Splay Tree.
    • Unembed status: this means CMarkupPointer removes the CTreePos from the Splay Tree and frees it.

    The following graph describes the interactions involving the splay tree.

    Figure 8. Splay tree graph

    Going back to our four questions, we can now attempt to answer them.

    Why does it trigger an onerror event?

    From Figure 1’s Javascript code, we can see e_2.onerror sets a handler function. At line 22, e_2.swapNode will trigger DOM tree’s changing; this calls the CObjectElement::CreateObject function. This function checks the object’s CLSID. Because e_2’s CLSID is not set, it triggers the onerror event handler.

    In the handler, at line 22, the Javascipt code r.insertNode(e_2) will change the DOM tree once again and change CObjectElement::CreateObject as well; because e_2 has no CLSID , it will again trigger the onerror event handler once again. The second time the this handler runs, at r.setEnd(document.all[1],0)” , it frees the CTreePos object.

    Why does it create the CTreePos object?

    From Figure 6, the CTreePos object is created in calling the CDomRange::InsertNode function. We can map this function to Figure 1’s line 19: r.insertNode(e_2). The CDomRange::InserNode function will insert elements into the DOM tree. The function is called Doc::CutCopyMove to modify the DOM tree and takes several arguments. The first CMarkupPointer type argument is the source start location in CMarkup (DOM tree) . The second CMarkupPointer type argument is the source end location in CMarkup (DOM Tree). The third CMarkupPointer type argument is the target location in CMarkup (DOM Tree).

    Doc::CutCopyMove will copy or move the source sub DOM tree to the target location in DOM tree. Because of the use of the Splay Tree algorithm (which uses CTreePos as a node), the function needs to create a CTreePos object and add it to the SplayTree for source CMarkup (DOM tree) and target CMarkup (DOM Tree). Doc::CutCopyMove calls CMarkup::DoEmbedPointers to let the CMarkupPointer change to embed status. Finally, the CTreePos object is created. The UAF CTreePos object is created for the e_1 JavaScript element.

    Why does it free the CTreePos object?

    From the call stack trace when the CTreePos object is freed (Figure 4), we can find CDomRange::setEnd. This function can be mapped to line 17 in Figure 1: r.setEnd(e_1,0). That means the CTreePos object is in the implementation of setEnd. The CDomRange::setEnd function wants to replace the original end point with a new end point. This function finally calls CMarkupPointer::MoveToPointer to move to the specific DOM tree location. It will first call CMarkupPointer::UnEmbed to change this CMarkupPointer object to unembed and remove CTreePos from the Splay Tree and free it. The JavaScript code r.setEnd‘s argument is the e_1 element. So the CTreePos object related with the e_1 element is freed.

    Why does it use the freed object again?

    In Figure 7, under the red line is the function call for CSpliceTreeEngine::InsertSplice. Column B is CSpliceTreeEngine::InsertSplice+0x13ff. Column C is CSpliceTreeEngine::InsertSplice+0x6EDD4A. Column B is the free call stack trace and Column C is the “used again” crash call stack trace. This means that both “free” and “used again” happen in one function called CSpliceTreeEngine::InsertSplice. We trace the execution flow in this function, and find the following:

    Figure 9. Assembly code

    Instruction 636898C4, eax is the address of the UAF CTreePos Objects. The function saves the address to a local variable var_1E4. Then, it proceeds to 6368AA9A.

    Figure 10. Assembly code

    At 6368AA9A, it calls a virtual function CObjectElement::Notify. We can find here the call stack trace from Figure 7’s column B. This means when running this call, it encounters an error and calls the onerror event handler . That frees the CTreePos object. However, the CSpliceTreeEngine::InsertSplice function local variable var_1E4 holds a reference to this freed object. It then proceeds to 63D7735B.

    At 63D7735B , it calls CElment::RecordTextChange ForTsf with var_1E4 as the second argument. When this function is run, if any instruction accesses the contents of the CTreePos object, a crash occurs.


    In brief, the UAF issue’s root cause is that under the event interaction context, CSpliceTreeEngine::InsertSplice doesn’t handle local variable reference validation properly.

    DOM is based on event mechanisms. Under complex event interaction contexts, it is a significant challenge to solve UAF issue completely. However, in recent patches Microsoft has introduced memory protection in Internet Explorer, which helps mitigate UAF issues (especially in cases where a UAF object is referenced from the call stack).

    This highlights one important reason to upgrade to latest versions of software as much as possible: frequently, new techniques that make exploits more difficult are part of newer versions, making the overall security picture better.

    Trend Micro Deep Security protects users against this particular threat. The following rule, released as part of the regular updates released in June is applicable:

    • 1006036 – Microsoft Internet Explorer Memory Corruption Vulnerability (CVE-2014-1772)
    Posted in Exploits, Vulnerabilities |

    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:

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

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

    Posted in Exploits, Vulnerabilities | Comments Off

    In the recent Microsoft security bulletin for Internet Explorer, we found an interesting improvement for mitigating UAF (User After Free) vulnerability exploits.  The improvement, which we will name as “isolated heap”, is designed to prepare an isolated heap for many objects which often suffers from UAF vulnerabilities.

    Let’s use Internet Explorer 11 as an example. Before it was patched, the function CHeadElement::CreateElement allocates memory space from the heap. The code is as follows:


    Figure 1. The function CHeadElement::CreateElement

    From Figure 1, we can see the memory space is allocated from the heap g_hProcessHeap, which is the IE default heap. In other words, all these IE objects share the same heap.  After the patch, in the sample location, the code was changed to the following:



    Figures 2 and 3. The function CHeadElement::CreateElement after the patch

    From Figures 2 and 3, we can see that Internet Explorer now allocates memory space from the heap g_hIsolatedHeap. In other words, these class objects which use the isolated heap do not share the same heap with IE’s other objects.

    How can an isolated heap mitigate UAF vulnerability exploits?

    The first routine of UAF vulnerability exploits is to use controlled objects to occupy the memory space which is owned by the UAF object. Some recent Internet Explorer zero-day vulnerabilities such as CVE-2014-0322 and CVE-2014-1776 used this technique.

    We can summarize the technique of occupying space in the following steps:

    1. Use String or Array to make a buffer which can be controlled by attacker.  For example: “var d=b.substring(0,(0x340-2)/2);
    2. Create an IE element object.  For example: “g_arr[a]=document.createElement(‘div’)
    3. Trigger vulnerability to free the target object.
    4. Set the attribute of the objects which is created by step 2 for many times with the String which is created in step 1. For example:



    In step 4, IE will allocate memory space in the heap g_hProcessHeap.  In the example for step 4, we can see the following part of the call stack:


     Figure 4. The function CAttrArray::Set() calling the function RtlAllocateHeap()

    In figure 4 we see CAttrArray::Set() calling the function RtlAllocateHeap(). The call stack is done with the following code:


    Figure 5. It uses RtlAllocateHeap with heap “g_hProcessHeap” and then copies the String ‘s data to this buffer.

    Before the latest patch, if the RtlAllocateHeap has the correct size, the probability that an attacker-controlled buffer could occupy the freed object’s memory space is high. But after the latest patch, the freed object is allocated in heap g_hIsolatedHeap, so there is no probability that the freed object memory space is occupied by the attacker-controlled buffer. The solution is a good way to mitigate UAF vulnerability exploits.

    From the patch‘s code,the heap g_hIsolatedHeap is used by HTML and SVG DOM Elements (CXXXElement) and supporting elements such as CTreeNode, CMarkup, CAttribute and so on. These objects have a high probability of having the UAF vulnerability, so it is important that they are secured through the isolated heap.

    Can the isolated heap solution mitigate UAF vulnerabilities completely?

    No solution is perfect. The improvement implemented by Microsoft raises the difficulty in creating an exploit, but it does not eliminate the vulnerability completely. There are two theoretical ways to bypass this protection:

    1. If attackers can find an object which meets the following three criteria instead of String:
      1. Allocated with the isolated heap.
      2. Correct size for the UAF object.
      3. Easily control the content of the object.

      What is not clear is if attackers can find a reasonable way to perform the above attack.

    2. Many objects are still using the process heap, not the isolated heap. If these objects encounter UAF vulnerability, the isolated heap solution doesn’t work. However, Microsoft can easily add objects to use the isolated heap if this becomes a problem down the road.

    We are glad that Microsoft is continuing to improve the security of Internet Explorer and mitigating the abuse of vulnerabilities. While the isolated heap is not a perfect solution, it represents a significant improvement that will help mitigate attacks of this type moving forward.

    Posted in Vulnerabilities | Comments Off

    Last week, Adobe released an advisory disclosing a new zero-day vulnerability in Flash Player.

    Looking into the exploit code used in attacks targeting this vulnerability, we found several interesting ties to other vulnerabilities – not all of them for Flash Player, either. To explain this, we will discuss the highlights of how this exploit was performed.

    Exploit highlights

    At its core, the vulnerability is a buffer overflow that occurs when parsing a compiled shader in a Flash object. The overflow overwrites an adjacent memory buffer, which has a vector object within it. The attacker overwrites the adjacent vector object’s length. From here, the attacker carries out some processes and is eventually able to run arbitrary shellcode.

    This exploit first uses a buffer overflow to overwrite the length of an adjacent vector object. This corrupt vector can be used to assign very large length values to the adjacent vector object. This vector object is then used to browse the system’s memory space and find the target data, as well as rearrange memory layout. This particular method is fairly common, and was used by CVE-2013-0640 (Adobe Reader), CVE-2013-3163 (Internet Explorer), CVE-2014-0322 (Internet Explorer), and CVE-2014-1776 (Internet Explorer).

    This corrupted vector’s element is used to locate the flash object FileReference‘s address, and replace it with a fake virtual table pointer.  The fake virtual table only contains the Cancel function, which points to the shell code. Calling FileReference.Cancel runs the arbitrary shellcode of this exploit. This is similar, but not identical to, recent exploit techniques used in CVE-2014-0322 and CVE-2014-1776, which use the Sound object, and trigger with Sound.toString().

    To defeat DEP (Data Execution Prevention, a technique used to harden systems against exploits) is relatively simple, since the attack has full control of the memory space. The attacker searches for a specific function, which is located in the Flash ActiveX plugin (Flash32_12_0_0_70.ocx). The function takes two parameters (buffer address and buffer length) and makes the buffer executable. This address is used to replace the fake FileReference object ‘s Cancel function address. After this call, the first stage shellcode become executable. Note that this is all done without the use of ROP (return-oriented programming) exploit techniques at all.

    Trend Micro Solutions

    Adobe has rolled out updates to Adobe Flash that patch this vulnerability. This would update users to Flash Users of Trend Micro products have various solutions available to help deal with this attack: the browser exploit prevention technology in Titanium 7 proactively detects websites that attempt to exploit this vulnerability.

    Products with the ATSE (Advanced Threats Scan Engine), such as Deep Discovery,  have heuristic rules which detect attacks using this vulnerability. These attacks are detected as HEUR_SWFJIT.B with ATSE pattern 9.755.1107 since April 22. Our other products detect these malicious Flash files as SWF_EXPLOIT.RWF.

    Update as of May 07, 2014, 10:43 P.M. PDT

    Trend Micro Deep Security and OfficeScan Intrusion Defense Firewall (IDF) have released a new deep packet inspection (DPI) rule to protect against exploits leveraging this vulnerability:

    • 1006031 – Adobe Flash Player Buffer Overflow Vulnerability (CVE-2014-0515)
    • 1006044 – Restrict Adobe Flash File With Embedded Pixel Bender Objects
    Posted in Exploits, Vulnerabilities | Comments Off


    © Copyright 2013 Trend Micro Inc. All rights reserved. Legal Notice