A New Zero-Day of Adobe Flash CVE-2015-0313 Exploited in the Wild

Just yesterday Adobe announced a zero-day vulnerability in Adobe Flash Player version 16.0.0.296. The zero-day exploit is delivered by a lesser known Exploit Kit - HanJuan - potentially attacking a large number of users. Since the attack is exploiting Adobe Flash, the malicious code will successfully execute in various browsers and different Windows versions.

We've seen a surge in the exploitation of Flash recently. We just finished analyzing zero-day vulnerability CVE-2015-0311 that was used by the prevalent Angler exploit kit to deliver malware and infect unsuspecting users. And now CVE-2015-0313 has appeared in the wild.

The vulnerability is a use-after-free vulnerability caused by a bug in how Flash handles the FlashCC (previously Flash Alchemy) "fast memory access" feature (domainMemory), when the last is used by flash Workers (Flash threads).

Before we dive into the vulnerability details, we'll explain the important Flash components involved in the exploit.

What are Workers in flash?

Not too long ago Adobe added support for background threads, which are represented in ActionScript as "Workers." The purpose of a worker is to give the developer the possibility of running simultaneous tasks without freezing the Flash application - this is an abstraction layer to support multi-threading within Flash.

What is a Shared Property?

Adobe's documentation includes the following details about shared properties:

[1] "The most basic way to share data between workers is to use a shared property. Each worker maintains an internal dictionary of shared property values. The properties are stored with String key names to distinguish between the properties."(Adobe)

Shared properties allow for the sharing of objects and data between workers. These objects are mutable and can be set or read by a worker using the setSharedProperty/getSharedProperty methods.

What Actually Happens?

Flash supports FlashCC/Alchemy project, which is a feature allowing C/C++ applications support within Flash. As part of this feature, Adobe provides the possibility to access the process memory directly using ActionScript, this feature is named "fast memory access". This fast memory access is achieved by setting the current domain memory data to a predefined ByteArray data, as follows:

ApplicationDomain.currentDomain.domainMemory = this.ByteArray1;

When this Byte Array is freed from memory, our flash application deletes the reference from the domain Memory object. However, if this Byte Arrays is freed by another thread/worker, then the domain Memory object still holds a pointer to an already freed memory. Such a condition is a security risk and is usually classified as a use-after-free vulnerability. Using the reference to a freed memory area, it is possible to use/access the heap memory block directly.

The exploit uses heap spraying to fill this freed memory with Vector Objects and corrupt the size of a given vector setting it to a very large size. This corrupted Vector will later be used to access the entire memory of the browser process and to gain code execution over the machine.

Let us try and take a look at the malicious code reproduced in our labs to understand the vulnerability:

The following ActionScript code is responsible for:

1. Create a Worker and set up the communication channels between the main application and the worker.
2. Create and share a Byte Array with the Worker through Shared Properties
3. Fill the Byte Array (byteArry1) with data.
4. Set domain Memory (FlashCC) binaryData to byteArry1's memory region – This will create a reference inside domain Memory. An exploit will use this reference to corrupt a vector's size property and eventually get access to the entire browser's memory.
5. Send a message (just a string - "ghbdtn" – it's value is of no importance) through the communication channel to inform the worker to free ByteArray1 from memory (while Domain Memory still holds a reference).

The Worker receives a message ("ghbdtn") from the main application and does the following:

1. Frees ByteArry1 by calling .clear(), however at this point Domain Memory still holds a reference to it.
2. Allocate ByteArray2 over the freed space of ByteArry1 and fill it with 0xBBBBBBBB dwords (important for the exploitation stages).
3. Pass the Byte Array object to the main worker through set Shared Property.
4. Send back another message ("vbh") to inform the Main worker to free ByteArray2.

At this point, the Main application frees the heap object of the Byte Array without removing the reference from "Domain Memory":

After analyzing the ActionScript code we could identify that exactly the same heap spray and a very similar exploitation technique was used in CVE-2015-0311 that leads us to believe that this vulnerability was discovered by the same researcher.

The following screenshot shows the crash caused by the use after free vulnerability reproduced in our labs:

According to TrendMicro, the first to identify the malvertisement attack, and evidence collected by Kafeine, the attack was delivered through malicious advertisements served in very popular sites like dailymotion.com with a high potential of reaching a very wide number of users, as currently no patch is available for this vulnerability.

According to TrendMicro: "Visitors of the popular site dailymotion.com were redirected to a series of sites that eventually led to the URL hxxp://www.retilio.com/skillt.swf"