Analyzing CVE-2015-0313: The New Flash Player Zero Day

Adobe has started rolling out an update to Flash Player which fixes the zero-day vulnerability we discussed earlier this week. This particular vulnerability can be exploited via all major browsers (Internet Explorer, Firefox, and Chrome); however Chrome users are protected by that browser’s sandbox for its Flash plugin, protecting end users from any attacks. The patch brings the newest version of Flash Player to

This particular vulnerability is a use-after-free vulnerability. Like CVE-2015-0311, the memory referenced by domainMemory was freed before it was used.  Other portions of the exploit are similar to CVE-2015-0311, such as the obfuscation, ROP techniques, and shellcode. After analysis of the exploit kit pages (we would like to thank Kafeine for working with us on this analysis), we’ve found that it is possible that this exploit was first used by the Hanjuan exploit kit.

Despite these similarities, however, there are some differences between the earlier zero-day and this one.

Background: ActionScript workers

Before we can analyze this vulnerability’s root cause, we need to introduce some concepts about Flash and its scripting language, ActionScript.

ActionScript 3.0 uses the Worker object to help developers implement high performance applications. Objects can be shared between different workers, as explained in the ActionScript 3.0 Developer’s Guide.

The most important thing to understand is that workers share the underlying memory of a shareable ByteArray object. No new memory will be allocated when calling worker.setSharedProperty on a shareable ByteArray object. Changes by one worker on the shareable ByteArray object memory content will be seen by other workers.

Root cause analysis

The exploit code we acquired uses a worker object. There are communications between the main execution thread and the worker using a shared property and MessageChannel. MessageChannel is used to synchronize the main thread and the worker thread; the shared property is used to actually trigger the vulnerability.

The vulnerability’s trigger flow can be simplified as following 3 steps.

  1. [Main Thread] A shareable ByteArray object is set to be shared between the main thread and worker thread by calling setSharedProperty.
  2. [Main Thread] Set this shareable ByteArray object memory to domainMemory.
  3. [Worker Thread] Worker thread gets the shareable ByteArray object through worker shared property by calling getSharedProperty, and then clears the memory by calling ByteArray::Clear.

Why does domainMemory reference the freed memory?

In step 3, the worker thread clears the memory of the shareable ByteArray by calling ByteArray::Clear. It is this action that triggers the bug.

My debugging found that before the memory is cleared in the worker thread, the underlying buffer is referenced by the shareable ByteArray object and domainMemory. The ByteArray::Clear function will free the underlying buffer and set the pointer to NULL, but it does not notify domainMemory to change the memory reference. This is a logic bug, which is not present in other functions.

Some functions, such as ByteArray::Length, will notify domainMemory to change the memory reference if they are called in a worker thread. Other functions, such as ByteArray::Compress and ByteArray::Uncompress, will throw an ArgumentError when called on a shareable ByteArray which is referenced by domainMemory within a worker thread.

The following pictures show the differences before and after calling ByteArray::Clear:

Figure 1. Memory references before clear function call

Figure 2. Memory references after clear function call

ROP and Shellcode

This vulnerability’s ROP and shellcode are similar to those used by CVE-2015-0311. The ROP gadgets used are in the following picture:

Figure 3. ROP gadgets

The functions used by the shellcode are in the following picture. It uses winhttp functions to download the actual malware payload.

Figure 4. Shellcode function call

Figure 5. Payload downloaded (click to enlarge)

We advise users to update their versions of Flash as soon as possible, if they haven’t already. More information about Trend Micro solutions for this threat are available in our support portal.

Post from: Trendlabs Security Intelligence Blog – by Trend Micro

Analyzing CVE-2015-0313: The New Flash Player Zero Day

Read more: Analyzing CVE-2015-0313: The New Flash Player Zero Day

Incoming search terms

Story added 5. February 2015, content source with full text you can find at link above.