Advanced Exploitation Of Flash Vulnerability In The Wild

New Flash exploit is extremely effective against the security technologies that many depend on for shelter -- is this a sign of things to come?

Tom Parker, Contributor

June 19, 2011

4 Min Read
Dark Reading logo in a gray background | Dark Reading

Not a day goes by lately without a new piece of malware making the rounds, with many anti-virus firms touting collection figures in excess of ten thousand new samples per day. It seems that it is becoming more and more common to see malware leveraging unpatched flaws in client side software: the most common targets, of course, being Web browsers and plugin interfaces that they expose. In many regards, while such malware may leverage an unpatched flaw as its initial entry vector, they aren’t necessarily advanced in their authorship.

Many exploits are written to target very specific environments, where success is more or less guaranteed. For example, it is commonplace for malicious websites to implement some basic JavaScript to identify the target software version and operating system in order to avoid target configurations where exploit failure is more likely. A simple example of this would be operating systems under which technologies such as DEP (data execution prevention) and ASLR (address space layout randomization) are likely to be enabled.

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.

About the Author

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights