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

  • Recent Posts

  • Calendar

    July 2014
    S M T W T F S
    « Jun   Aug »
     12345
    6789101112
    13141516171819
    20212223242526
    2728293031  
  • About Us
    TrendLabs Security Intelligence Blog(breadcrumbs are unavailable)

    Archive for July 17th, 2014




    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.

      Jul-UAF-3
      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



    The topic of open Wi-Fi and public hotspots has been in the news again, for several reasons. Last month, the Electronic Frontier Foundation launched OpenWireless.org, a project to create router firmware that would provide open wireless access to anyone in range of the user’s router.

    Notionally, in addition to providing Internet access to everyone who needs it, it would make everyone’s Internet more private by removing the connection between one’s identity and IP address, since anyone could be using the open Wi-Fi to gain access. This would make surveillance and tracking based on the IP address unreliable.

    Well-intentioned as this may be, people actually running this is not a good idea. Let’s assume that this can be done in such a way that your private network traffic is segregated from the open Wi-Fi traffic. Your own network traffic would not be at risk of exposure, but that’s not the only risk.

    What goes out on your Internet connection ISP is your responsibility. You’re likely to end up in legal hot water if illegal behavior is carried out via your IP address.  The potential for abuse is extremely high. High bandwidth usage by “guests” can also eat up your data cap, resulting in either a throttled connection or a large bandwidth bill at the end of the month.

    Similar initiatives have been tried in other countries by projects like RedLibre and Guifi (both in Spain). However, the adoption of these has been rather limited. The implementation of these projects may have differed, but ultimately the risks are enough to deter users from participating in them, no matter how well-intentioned.

    The other story that’s put public Wi-Fi in the news was Comcast Internet turning the modems of 50,000 subscribers into residential Wi-Fi hotspots. This hotspot would be separate from any Wi-Fi network the user established, and would be for the use of all Comcast subscribers. Before someone could log into this public hotspot, they would have to enter their Comcast username and password.

    Other ISPs are bound to come up with similar public Wi-Fi hotspots. Two questions come to mind here. If I am a subscriber, should I opt out my network of this? Is it safe to log onto these public hotspots? Let’s deal with the first one.

    In theory, the risks to users are far less in this scenario than with a purely open Wi-Fi scenario. Any data consumed by this access point does not count against the user’s data cap. Abuse of the hotspot is something that would be the responsibility of the ISP, not you. So, there’s no risk, right?

    Not exactly. From a technical perspective, the biggest problem would be the separation of the hotspot’s traffic from your own. Unfortunately, wireless routers don’t have a good track record when it comes to software vulnerabilities. The existence of a vulnerability that exposes your network can’t be ruled out.

    The real risk for is for people who want to use these hotspots. The above risk of vulnerable firmware applies to would-be users, too: it’s entirely possible that the network traffic of guests could be exposed to an attacker running a malicious version of the router firmware. It’s an inherent risk of connecting to a network that you may not completely trust.

    Another risk is it enables other attacks that put your ISP credentials at risk. As some tech sites have noted, it is very easy to set up a fake hotspot with the same Service Set Identifier (SSID) as that used by the public hotspots offered by ISPs. Since these public hotspots use a captive portal to ask for your ISP’s credentials (to validate that you are a customer), an attacker can create a fake version of that portal to steal the ISP login credentials.

    Until a better technical situation for open Wi-Fi becomes available, users will have to be careful in dealing with situations like this. An earlier blog post of ours also discussed using open Wi-Fi safely, with the use of virtual private networks (VPNs) being the most important tip there. Meanwhile, running one of these open wireless networks, given all the possible risks, is not a very good idea.

     
    Posted in Mobile | Comments Off


     

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