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

  • Recent Posts

  • Calendar

    October 2014
    S M T W T F S
    « Sep    
  • About Us
    TrendLabs Security Intelligence Blog(breadcrumbs are unavailable)

    Author Archive - Jack Tang (Threats Analyst)

    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,(0×340-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

    In between the end of support for Windows XP and the Heartbleed OpenSLL vulnerability, one good bit of news may not have been noticed: the Microsoft Word zero-day vulnerability  (CVE-2014-1761) reported in late March was fixed.

    We have since looked into this attack and found that the exploit was created by an attacker with some skill, resulting in what can only be described as a sophisticated exploit.

    It’s quite fortunate that Microsoft was able to patch this vulnerability quickly, as its sophistication and the widespread use of Microsoft Word in enterprises meant that it would have been a highly tempting target for attackers to exploit. While this particular attack is no longer effective (as we will show later), we cannot rule out future attacks that will target the same vulnerability.

    Basic Flow of the Exploit

    This vulnerability is exploited when a user opens an RTF file in Microsoft Word, or previews/opens an RTF email in Outlook (using Word as the RTF viewer).

    The basic flaw at the core of this vulnerability is an out-of-bounds array overwrite. After overwriting, the memory now contains a fake object whose virtual table pointer points to a fake virtual table which is controlled by RTF control words with specially set values chosen by the attacker. The attacker used opcode addresses which point to addresse ranges used by MSCOMCTL.OCX.

    This particular executable is vulnerable to exploitation because it does not have address space layout randomization (ASLR) enabled; why this has been done is unknown. Carefully chosen portions of code (also known as ROP gadgets) from the above .OCX file are used to compose the first stage shellcode, which starts at the 0×40000000 memory address. The first stage shellcode finds the opened RTF file handle in the winword.exe process and maps the buffer into process space, which starts from the file offset 0xF004 and a length of 0×1000, to the process address 0×40002000. This makes up the second stage of shellcode.

    The second set somewhat unusually checks the Windows Update log of the affected system. If it sees that patches have been applied on or after April 8 (the regular Patch Tuesday date), it stops running. Otherwise, it drops its payload (named svchost.exe) and runs it. This particular attack is no longer effective today because of the April 8 date check, but it would be trivial to use similar code without the date check, especially with samples out in the wild to provide guidance to unaware attackers.

    In our analysis, we noticed that this particular sample crashes, but does not successfully exploit, older versions of Office 2010 without the latest updates installed as of late March (we found this using 14.0.4730.1010). Newer versions that were patched as of the discovery of the zero-day were successfully exploited.

    The sample is also similar to exploits for CVE-2012-2539, which also use an invalid value for the RTF control word listoverridecount, like this exploit.

    Solutions and Prevention

    As we noted in our first post on this threat, even before the official Microsoft patch (described in MS14-017) was released, we were able to heuristically detect this particular threat via Deep Discovery using the ATSE (Advanced Threats Scan Engine) and prevent users from being affected. However, we still recommend that users apply this patch in order to ensure the security of their systems.

    While other threats like those in online applications (such as browsers and plugins) or online services and protocols (like Heartbleed) may garner more attention, this threat is a reminder that more conventional threats – like exploits in RTF files – have not gone away. If anything, we’ve been observing RTFs used in several attacks recently, as carriers of CPL downloaders (here and here) and backdoors.

    We cannot rule out the possibility that CVE-2014-1761 will continue to be a threat moving forward, especially since many users will forget to update their installed version of Microsoft Word. For these users, our heuristic detection will be able to help reduce the risks of these attacks.

    Posted in Exploits, Vulnerabilities | Comments Off

    Recently, security researchers disclosed two Java native layer exploits (CVE-2013-2465 and CVE-2013-2471). This caused us to look into native layer exploits more closely, as they have been becoming more common this year. At this year’s Pwn2Own competition at CanSecWest, Joshua Drake showed CVE-2013-1491, which was exploitable on Java 7 running on Windows 8. CVE-2013-1493 has become a popular vulnerability to target in exploits kits such as Blackhole.

    To understand why these exploits are becoming more common, some understanding of Java’s architecture is helpful. Java exploits can be divided into two types: Java layer exploits and Java native layer exploits.

    Figure 1. Java security model

    The above graph shows the Java security model. Java layer exploits target vulnerabilities in the Java layer runtime, which lets applications bypass the Security Manager and call high privilege functions. These exploits have the following characteristics:

    • Can be created with less effort, because attackers need not bypass operating system-level protections.
    • Are cross-platform (i.e., work with multiple operating systems)

    Similarly, Java native layer exploits target the Java native layer runtime. These exploits are harder to create, as they need to bypass OS-level protections like ASLR and DEP. In addition, the skills needed to create native layer exploits are more difficult to acquire.

    Figure 2. Timeline of common Java vulnerabilities

    In the past, Java layer vulnerabilities were more common, but that is no longer the case. Before 2013, there was a 3:1 ratio of Java layer vulnerabilities to Java native layer vulnerabilities. Starting this year, however, we are now seeing more native layer flaws. Why is this the case?

    • A large amount of the vulnerabilities of are present in the Java native layer code. In the June 2013 Java SE Critical Patch Update Advisory, approximately half of all the vulnerabilities fixed were in the Java native layer code.
    • Attackers are becoming more skillful in creating exploits. In the past, while there were many native layer vulnerabilities, less exploits were present because attackers did not always have the skill to create the necessary exploits.

    This year, however, attackers clearly have the capability to take advantage of native layer vulnerabilities. Two methods of exploitation are becoming more common,

    One is to make use of a Java array length overflow to tamper with the java.beans. Statement object’s AccessControlContext member. To do this, the following steps are necessary:

    1. Prepare a Java Array object on a heap.

      Figure 3. Step #1

    2. Trigger a Java native layer vulnerability. The array object’s length is overflowed to a very large value.

      Figure 4. Step #2

    3. An attacker can then use the array object to get or set the following buffer precisely. They can tamper with the following java.beans.Statement object’s acc field, which points to a AccessControlContext object. In general, the acc field will be tampered to point to a full permission AccessControlContext object. This will let arbitrary code be run on the affected system.

      Figure 5. Step #3

    This exploit method requires that both the buffer which can be used to trigger vulnerability and the buffer which needs to be overwritten are in the same heap. It requires some knowledge and skill to ensure that this is the case. In addition to this, information leaks and ROP shell code attacks were demonstrated at Pwn2Own 2013. It gets the module base address by targeting a Java native layer vulnerability and constructing ROP shell code to hijack the execution context. We believe that 2013 will see more similar exploits along these lines.

    We urge users to carefully evaluate their usage of Java is necessary and ensure that copies of Java that are used are updated, to reduce exposure to present and future Java flaws.

    Update as of 9:28 AM PDT, Sept. 2, 2013

    Trend Micro Deep Security provides protection for threats targeting CVE-2013-2465, CVE-2012-4681, CVE-2012-1723 via the following rules:

    • 1005598 – Identified Malicious Java JAR Files – 3
    • 1004870 – Identified Suspicious Jar File
    • 1005093 – Java Applet Field Bytecode Verifier Cache Remote Code Execution Vulnerability
    • 1005640 – Oracle Java storeImageArray() Invalid Array Indexing Vulnerability


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