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 - Peter Pi (Threats Analyst)

    Last week a major zero-day vulnerability was found in Adobe Flash Player. Over the weekend, Adobe released an update to fix the vulnerability: users who have enabled auto-update already received the newest version ( Our analysis has confirmed that the vulnerable code has been modified.

    The update will be available for manual download later this week. Users of Chrome and newer versions of Internet Explorer will receive updates for their included versions of Flash Player at around the same time.

    Looking into the samples we acquired, we found that the actual Flash file was embedded within the malicious .SWF file. In addition, the actual file was heavily obfuscated.

    Once we removed the obfuscation, we were able to analyze the vulnerability in full and find out how the exploit works. Before going into the details, we will point out one curious little fact: some of the code fragments are similar to exploits targeting CVE-2014-8439. It is possible that the same person is responsible for both exploits.

    Vulnerability Root Cause

    Our analysis found that this is a use-after-free (UAF) type of vulnerability. In this case, the memory referenced by domainMemory is freed. This vulnerability can be used to read and write into memory, and an attacker can use this ability to run arbitrary code.

    This vulnerability is triggered by the following steps:

    1. Create a new ByteArray, and write lots of data to it, then compress the contents.

      Figure 1. ByteArray creation code

    2. Overwrite the ByteArray compressed data from position 0x200 and set ByteArray to domainMemory.

      Figure 2. Overwriting ByteArray

    3. Uncompress the ByteArray data. Because of the actions in the previous step, this will result in an IOError exception. The code catches the exception, then uses another ByteArray to hold the freed memory’s place, this ByteArray is buffered with 0xBBBBBBBB.

      Figure 3. IOError and catching the exception

    4. Clear the place holder data in ByteArray.

      Figure 4. Freeing the 0xBBBBBBBB ByteArray memory

    Why Does domainMemory Still Reference The Uncompressed Data Buffer?

    In the AvmPlus project code, we found that the bug is in the ByteArray::UncompressViaZlibVariant function. The function is designed this way: it will allocate a new buffer for storing the uncompressed data first. If the decompression is successful, it will notify domainMemory to use the new buffer. If the decompression fails, it will not notify domainMemory to use the new buffer, and instead, it will free the newly created buffer.

    This seems correct, but in the decompression process, the allocation for the new buffer will grow bigger. The class Grower will handle the buffer’s dynamic growth. After this growth is complete, the destruction of class Grower will notify domainMemory to use the expanded buffer. What we end up with is domainMemory using the new buffer during the decompression process. If this fails, the newly created buffer is freed. This breaks the original logic of ByteArray::UncompressViaZlibVariant: even if the decompression fails, domainMemory uses the new buffer.

    This is why after performing the above steps, domainMemory now points to a freed memory space filled with 0xBBBBBBBB, the exploit can now use intrinsic instructions to read and write the freed memory space.

    Figure 5. Reading the freed memory space

    Like most recent Adobe Flash exploits, the exploit code controls the memory layout and put vectors beside the freed memory. This allows the vector length to be overwritten, which allows the attacker to arbitrarily read and write into the memory.

    Figure 6. Overwriting memory

    We can see the memory layout changing during uncompression, up to the vector length being overwritten in the following pictures. The use-after-free memory address is 0x05120000 in my debug environment.

    Figure 7. The memory layout after uncompressing (the header data is successfully uncompressed)

    Figure 8. The memory layout after allocated the 0xBBBBBBBB ByteArray

    Figure 9. The memory lay out after freed the 0xBBBBBBBB ByteArray and sprayed Vectors

    Figure 10. The memory layout after overwrite vector length

    After the vector length has been overwritten to 0x40000000, the sample code can now read and write into arbitrary memory; this capability can be used by exploits to run arbitrary code. The exploit just triggers a fake virtual function call to execute shellcode.

    Trend Micro Solutions

    Trend Micro’s dynamic script emulation technology is able to successfully analyze even heavily obfuscated Flash files. This allows us to extract embedded .SWF files and monitor the vector heap spray behavior. As a result, we are able to provide a more complete analysis of exploits and provide complete protection to our users in a relatively short period of time.

    Our initial post contains details on our available solutions for this threat.


    Firefox OS is Mozilla’s foray into the mobile operating system field and promises a more adaptive mobile OS. But as mobile threats, in particular in the Android platform, has gained momentum, the question in everyone’s mind is – how safe is it?

    About a month ago, Telefonica announced that it had launched the Firefox OS – Mozilla’s mobile operating system – in Colombia and Venezuela. Separately, ZTE is also selling Firefox OS devices via their eBay store directly to end users.

    The Firefox OS uses uses a Linux kernel and boots into a Gecko-based runtime engine, which lets users run apps developed entirely using HTML, JavaScript, and other open web technologies.

    Overall, Firefox possesses good app permission management, but core processes (with more privileges) may become a target for exploits. In addition, HTML5 features may become sources of potential vulnerabilities.

    Firefox OS Architecture Overview

    The Firefox OS has to connect web-based applications to the underlying hardware. It does this using an integrated technology stack consisting of the following levels:

    Figure 1. Firefox OS stack

    Gonk consists of the Linux kernel, system libraries, firmware, and device drivers.

    Gecko is the application runtime layer that provides the framework for app execution, and implements the Web APIs used to access features in the mobile device.

    Gaia is the suite of web apps that make up the user experience (apps consist of HTML5, CSS, JavaScript, images, media, and so on).

    The Gecko layer acts as the intermediary between web apps (at the Gaia layer) and the phone. It also enforces permissions and prevents access to unauthorized requests.

    Application security

    Firefox OS also has its own application layer design. There are three kinds of apps: hosted apps, privileged apps and certified apps.

    Hosted apps can be installed from any website, without any further verification. This doesn’t grant the app any additional permissions besides those already exposed to a web site. Privileged apps are allowed to request more permissions, but they must be verified and signed by a Marketplace (i.e., app store). Certified apps, which have the most permissions, can only be pre-installed on the device by the manufacturer.

    Figure 2. B
    There is a B2G process in the Gecko layer that has high privileges running in the background, and every app will run in a content process with low authority. Every request to the device asked by an app needs to pass to B2G process first, and the B2G process will check the permissions of the app.


    Firefox OS also contains extensive sandboxing. Each app runs in its own worker space and it has access only to the Web APIs and the data it is permitted to access, as well as the resources associated with that worker space (Indexed DB databases, cookies, offline storage, and so on).

    In addition, apps communicate only with the B2G process, not with other processes or apps. Apps do not run independently of B2G, nor can apps “open” each other. The only “communication” between apps is indirect, and is mediated by the B2G process.

    Exploiting the B2G process

    The B2G process is a core process of Firefox OS. It is in the Gecko layer in the Firefox OS technology stack. If this process is exploited, an attacker can obtain high-level privileges (like root access.)

    Approximately a month ago, a vulnerability in Firefox 17 was found which could be used to run arbitrary code. We have confirmed that this vulnerability can also cause the B2G process to crash, and that we can also control the IP (Instruction Pointer). This would allow an attacker to run arbitrary code on the device with the privileges of the B2G process.

    Mozilla’s documentation itself states the exploitation of B2G process is a  possible attack point for Firefox OS. This is because that content process can send dirty data to the B2G process.

    HTML5 vulnerabilities

    Because the apps for Firefox OS are built using HTML5 apps, we can expect that the HTML5 vulnerabilities will be used to exploit Firefox OS in the future. Independent research has said that HTML5 features can be used to do memory fills for heap sprays.

    The HTML5 command Uint8ClampedArray can be used to fill memory with high efficiency and easy to write code. It is easy to find a steady address filled with the payload using Uint8ClampedArray. HTML5 Web workers to fill memory quickly in using multiple threads, reducing the amount of time necessary to fill the memory.

    In our previous study of HTML5, we tackled on how this can be abused and can result to various attacks, including spamming, unauthorized bitcoin generation, phishing and a browser-based botnet. Since these HTML5-based attacks will be memory-based, traditional antimalware solutions will be challenging.

    Though the Firefox OS may not enjoy the market of the Android OS, the use of HTML5 is gradually gaining traction among users (Amazon also accepts HTML5 for its apps). Thus, regardless of OS, we can expect that as more apps and sites will use HTML5, such attacks will increase in the future.


    We believe that Firefox OS will face attack like other mobile OS. The most harmful attack may be exploiting the B2G process. And, resources from browser exploitation would be useful for exploiting Firefox OS because it is Gecko based and its apps are written by HTML5. Users, on the other hand, will benefit from understanding the risks involved in using HTML5 and how they can avoid these. For more information, you may refer to our research paper HTML5 Overview: A Look At HTML5 Attack Scenarios.

    Update as of 5:30 PM PDT, September 12, 2013:

    Mozilla has confirmed that this vulnerability is present in Firefox OS, but it has been patched in the update to version 1.1.

    Posted in Mobile, Vulnerabilities | Comments Off


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