cve 2015-0313

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 16.0.0.305.

This particular vulnerability is a use-after-free vulnerability. Like CVE-2015-0311, the memory referenced bydomainMemory 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 thankKafeine 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 ByteArrayobject. 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 anArgumentError 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.

Trend Micro products have been protecting users from this attack from the beginning through different technologies.

The existing Sandbox with Script Analyzer engine, which is part of Trend Micro™ Deep Discovery, can also be used to detect this threat by its behavior without any engine or pattern update. The Browser Exploit Prevention feature in our endpoint products such as Trend Micro™ Security, OfficeScan, and Worry-Free Business Security blocks the exploit once the user accesses the URL it is hosted in. Browser Exploit Prevention also protects against exploits that target browsers or related plugins.

Trend Micro™ Deep Security, Vulnerability Protection (formerly the Defense Firewall plug-in for OfficeScan) andDeep Discovery customers with the latest rules also have an additional layer of protection against this vulnerability. Specifically, Trend Micro releases the following rules and patterns:

• Deep Security rule DSRU15-004
• Deep Packet Inspection (DPI) rule 1006468 for Deep Security and Vulnerability Protection (formerly the IDF plug-in for OfficeScan)

More information about Trend Micro solutions for this threat are available in our support portal.

Update as of February 4, 2015 12:55 A.M. (PST) – The entry has been edited to expound on the Trend Micro solutions for this threat.