What Adobe could learn from The Flying Wallendas

Analysis The Flying Wallendas were a legendary circus troupe that performed death-defying acts from a high wire without the use of nets or safety devices of any kind. Even when they performed their world-famous four-person, three-level pyramid act 50 feet in the air, patriarch Karl Wallenda steadfastly eschewed nets out of a belief they sapped the aerialists' concentration.

“He did feel that a net could cause you to be sloppy and not really train the way you should to prepare for a performance and therefore give you a false security,” Karl Wallenda's grandson, Tino, said recently from a performance in Greenfield, Massachusetts. “It makes the audience feel comfortable more than it makes us, the performers, feel comfortable.”

Perhaps the recently discovered attack targeting a code-execution vulnerability in Adobe's near-ubiquitous Reader application should raise similar concerns in the software arena.

The 15-page PDF was able to compromise PCs even when they ran Reader on versions of Microsoft Windows that are fortified with protections designed to lessen the damage from garden-variety bugs – such as the stack overflow being targeted in Reader. While white-hat hackers have demonstrated similar techniques over the past 18 months or so, the Reader exploit marks one of the first times they've been used in the wild, Nicolas Joly, a vulnerability researcher with Vupen Security, said earlier this week.

Constantly risking absurdity security

Particularly hard to defeat – or so we've been told – is a protection known as ASLR, or address space layout randomization, which Microsoft introduced with Windows Vista. It loads system components in a different memory location each time a machine is rebooted. That means that even when attackers have identified a vulnerability that allows malicious code to be injected into the operating system, they will have a hard time knowing where to find and run it.

The criminals behind the Adobe exploit worked around this feature by piggybacking their attack on a Reader file known as icucnv36.dll, which because of an oversight at Adobe, doesn't make use of ASLR. With a single mistake, a protection Microsoft spent years developing was undone. An Adobe spokeswoman said the company will “perform a thorough review of each vulnerability and our response” – including the lack of ASLR protection for the DLL file – so that changes can be made to the development process.

The attack also got around a second major defense that's known as DEP, or data execution prevention. The feature blocks the execution of code in specific memory regions, a measure that prevents the running of malicious shellcode even if it manages to sneak into a known region of computer memory. To do this, the attackers made use of a technique called ROP. Short for return oriented programming, it copies legitimate pieces of code already in use and reorders them in a way that significantly alters what they do.

ROP turned heads when it was successfully used at this year's Pwn2Own hacker contest. It's now becoming a staple of exploits used in the wild. And so are techniques, such as heap spraying and JIT spraying, that defeat ASLR.

And that should be a wake-up call for the entire industry.