This post is part one of two.
On August 14th, Adobe released a fix and an advisory for a vulnerability (CVE-2012-1535) in Adobe Flash Player. On Windows systems, Adobe Flash Player 11.3.300.270 and earlier versions are vulnerable. The advisory notes that this vulnerability has been used for targeted attacks.
We analyzed a sample with a SHA1 of 04804912C34E91B68222E27C3EF54A2FB9628DEA that we detect as Exploit:SWF/CVE-2012-1535.A. We’ve observed a small number of attacks using this vulnerability in the wild.
Vulnerability detail
The vulnerability is a typical integer overflow issue in the parsing routine for embedded fonts with CFF (Compact Font Format) format inside a SWF file. The integer overflow leads to corruption of the internal data structure of the process. This font data was modified from legitimate fonts and made malicious. We found many modifications were made to the font table data.
Figure 1 Part of malicious DefineFont4 record
The font is used in ActionScript code like that shown in Figure 2. The code tries to render texts on the Adobe Flash Player control using the malicious font data. The ActionScript code itself is not malicious at all, but this routine is used to trigger the vulnerable condition caused by malicious font data. So unlike many other Adobe Flash Player vulnerabilities, there is no problem with the AVM2 bytecode itself.
Figure 2 The code triggers the vulnerability
From our observations, the attackers are using a heap spray technique to exploit this memory corruption issue to code execution. The heap spray routine is shown below.
Figure 3 Heap spray routine
This malicious SWF content was delivered through Microsoft Word documents. But, there is no Microsoft Word vulnerability involved with exploitation process. As Microsoft Word supports the embedding of SWF content inside it, users are advised to be careful when opening Microsoft Word documents from unknown sources. However, Microsoft Word documents are not the only way in which this attack can be delivered. It is possible for this threat to be delivered via other methods.
The shellcode is run from the heap spray area and it searches through open file handles to grab a handle for a currently open Word document. After that, it searches for payload data inside the file and drops the data inside a temporary folder. The shellcode then runs the dropped file using the WinExec API. After that it displays a harmless Microsoft Word document to avoid making the user suspicious. This is very typical behavior where exploitation occurs through Word documents.
Part 2 of this blog will describe the fixes and mitigations for this exploit.
Acknowledgement
Thanks to Elia Florio, MSRC Engineering, for providing detailed information on mitigation technology.
Jeong Wook (Matt) Oh
MMPC
Leave a reply
