Microsoft Malware Protection Center: On March 14, Adobe released a security advisory (APSA11-01) warning of 0-day attacks affecting Adobe Flash Player (versions earlier than and including 10.2.152.33). These attacks were hidden inside Microsoft Excel documents that were used as a vehicle to deliver the exploit.
The Adobe Flash file embedded inside the Excel file is another carrier for the exploit. It loads shellcode inside memory, performs heap-spraying, and loads a Flash byte stream from memory to exploit the 0-day vulnerability, which is tracked as CVE-2011-0609.
We spent some time analyzing this new 0-day vulnerability. As with previous Flash Player vulnerabilities, this one abuses the bytecode verifier inside Adobe Flash Player. Adobe Flash files can contain ActionScript bytecode for AVM (ActionScript Virtual Machine). For this vulnerability, we’re talking specifically about ActionScript3 and AVM version 2. Ideally, the bytecode should be verified on a per-method basis, before and during the method’s execution inside the just-in-time virtual machine. But in some cases, the verification logic fails.
In the case of this vulnerability, the verifier failed to recognize a stack inconsistency after a series of operations and control flows. AVM security seems to be mainly dependent on the bytecode verifier and if it fails, the bytecode execution can be abused by the attackers.
We suspect this vulnerability was found using fuzzing technology from clean Flash files, because we found a file on the Internet that looks like it might have been used for the fuzzing. Through differential analysis between the original clean file and the exploit file, we could confirm the vulnerability.
We found that some of the old Flash Player versions were immune to these specific attack files, but, as the Adobe security advisory implies, it doesn’t necessarily mean that old players don’t have the vulnerability.
Details of the exploitation process.
To reliably exploit the vulnerability, heap-spraying is performed through AVM2. NOP-sleds are sprayed onto memory (image below) along with a Win32 shellcode.
Figure 1: Heap-spraying technique is used.
After the heap-spraying process, the actual attack code is loaded inside the Flash Player. The SWF file that triggers the vulnerability is converted from a hex-encoded embedded string object and executed as shown in the screen dump below:
Figure 2: A second flash file is loaded into memory.
The loaded SWF file contains a specially-crafted method that will cause the access of theoretically uninitialized memory. We say theoretically because in practice the said memory was initialized by the heap spray code, which enables the attacker to gain control of the execution.
We advise you that, for the time being, you don’t click any suspicious Excel files or hyperlinks. We’ve only seen this attack delivered through Excel files, but there is no reason why this attack cannot also be achieved through bare Flash files.