Recently we came into possession of an Adobe Acrobat PDF file that upon opening drops and executes a malicious binary. It was quite clear that this PDF was exploiting some vulnerability in order to drop its payload. And, during the analysis it soon became apparent that this vulnerability was not one we had seen in the wild before. What was even more surprising was that this vulnerability affects Adobe Flash—not Adobe Reader as we initially suspected. An issue in Adobe Flash is more serious. Most vulnerabilities are confined to one technology; for example, a vulnerability may affect a particular browser or a particular operating system, but it is rare for a vulnerability to span multiple platforms and products. This is not the case with Flash. Flash exists in all popular browsers and is also available in PDF documents. It is also largely operating system independent; therefore, the threat posed by this issue is not to be taken lightly. Flash has become an integral part of the modern browsing experience—becoming so ubiquitous that most users don’t even notice it. Thomas Ptacek of Matasano Security summed up just how serious Flash vulnerabilities are: “Why do you care about Flash exploits? Because in the field, any one of them wins a commanding majority of browser installs for an attacker.” (The full blog post is here: This New Vulnerability: Dowd’s Inhuman Flash Exploit.) The large user base of Flash presents attackers with a huge target audience and will certainly be too much for them to resist. Ptacek made the comment above when describing an article that Mark Dowd, research engineer with IBM ISS, published in April 2008 (Application-Specific Attacks: Leveraging the ActionScript Virtual Machine). This article detailed how he created a reliable exploit that took advantage of a very subtle memory corruption issue in Adobe Flash Player version 9.0.115.0. He gives a detailed account of how he overcame the many obstacles put in place by the Flash developers. This was quite an achievement. Whether it was intentional or not, this paper gave the reader a certain sense of security since it proved just how difficult it was to reliably exploit this issue and once the patch was available we could all put that nasty incident behind us. As expected, there were many people who were very happy to pick up Dowd’s research and use it for their own purposes. Since the release of Dowd’s paper we have seen widespread attempts to exploit Flash in the wild, but invariably they would all eventually use the exploit Dowd discovered. That is, until now. The authors of the exploit have managed to take a bug and turn it into a reliable exploit using a heap spray technique. Typically an attacker would entice a user to visit a malicious website or send a malicious PDF via email. Once the unsuspecting user visits the website or opens the PDF this exploit will allow further malware to be dropped onto the victim’s machine. The malicious PDF files are detected as Trojan.Pidief.G and the dropped files as Trojan Horse. We are in contact with the Adobe PSIRT team in relation to this issue. We urge our customers to ensure their antivirus definitions are up to date. Like the vulnerability Dowd discovered, it’s likely that we will see many attacks over the coming months that will attempt to exploit this vulnerability. As always, keep an eye out for the official patch from Adobe and ensure all products are up to date. As an extra safety measure, Vista users should avail of the UAC (User Account Control) feature as this will help mitigate a successful compromise. In this exploitation the PDF exploiting the vulnerability includes multiple Flash streams (FWS). One of these is used to dynamically create the shellcode and uses a heap spray technique to increase the chances of success of the exploit. In this attack the heap is loaded with 64 MB of data. Here is a snapshot of what the heap looks like: After the first step the attacker needs to somehow redirect execution to the heap in order to arrive at the malicious shellcode. This is where the vulnerability mentioned earlier comes in. Flash fails to sanitize instructions in a specific scenario here. The end function doesn’t expect the incorrectly constructed object and inadvertently passes execution onto the heap. Because of the actions taken by the attacker, execution will point to a region in the section prepared by the heap spray earlier. Execution will continue in the heap, which will ultimately result in the execution of the attacker supplied shell code. Testing shows that the vulnerability is exploitable on Windows XP and Vista, but the dropped executables do not run on Vista if UAC is enabled. Also, because this vulnerability affects Flash, any software that uses Flash is potentially vulnerable to this issue. (Words: Patrick Fitzgerald Analysis: Ka Chun Leung, Takashi Katsuki, Kevin Savage, Piotr Krysiuk)