On June 14th, Adobe released advisory APSB11-18 (CVE-2011-2110) which documents a "critical" vulnerability in Flash Player versions prior to 10.3.181.23 for Windows, Macintosh, Linux, and Solaris, and Adobe Flash Player 10.3.185.23 and earlier versions for Android. Almost immediately (and perhaps even prior), a number of malicious sites appeared, whose URL’s were sent via email to members of the D.C.-based defense community, and several large NGO’s.
In terms of the targeting of this threat, and the fact that it exploits a Flash 0-day, there is not a lot that is new here. But digging deeper into how the exploit code was written, there are some telltale signs that some real skills went into the development of this particular attack.
For the adversary, one of the big challenges of targeting Windows targets with client-side exploits these days is the increasing number of systems enabled with DEP and ASLR. Many choose to simply avoid this issue by reducing the probability that exploitation is even attempted against a system with these technologies enabled. This is really a bit of a cop-out though, and due to the rising number of potential targets avoided by this simple business logic, doing so will significantly reduce the yield of successfully exploited targets.
In or around 2008, vulnerability researchers discovered that an exploitation technique, very similar to return-to-libc style attacks, known as ROP (return oriented programming), could be leveraged to subvert DEP on Windows based systems supporting it (essentially, Windows XP SP2 and above). Conventional exploitation functions through placing arbitrary machine code on the stack and then calling back to it through a call, jump, or return.
This isn’t possible with DEP, as the locations you would normally store your code are generally marked as non-executable, so will just trigger a general protection fault if you attempt to execute them. In short, ROP allows an exploit to gain control over a process by leveraging chains of "useful" code (ending in a return), which already exist on an executable page (and are probably part of the exploited program), and are therefore "trusted" in the eyes of DEP. The exploit identified in the wild which exploits CVE-2011-2110 makes use of this technique – demonstrating some significant effort by the author to assure its success.
While you may be able to attain code execution, doing so with an unknown memory layout (due to ASLR) is rather like stabbing in the dark. You may succeed, but you’re more likely to fail, even with a large heap spray, which has its own drawbacks. The CVE-2011-2110 exploit solves this problem by identifying an information leak bug within Flash Player, which is used to determine the base load address of the flash DLL within the browser process. This then allows for relative addressing by the exploit, and ultimately code execution when coupled with the ROP technique that we already discussed.
This further evidences a trend of far more savvy exploit and malware authors on the wrong side of the law and as a result, will unfortunately mean even more very public compromises of large organizations, which seem to have set the trend for 2011.
Get your Flash installations updated!
Tom Parker is director of security consulting services at Securicon.