What Adobe could learn from The Flying Wallendas
Do security safety nets make Reader less safe?
Agentless Backup is Not a Myth
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.
Next page: Devs on a wire
COMMENTS
Time to switch to another language?
It's been many years since I programmed regularly (late 1980's, American university) but even then we were using Modula-2 or ADA. Then around that time C came on the scene.
For the life of me I don't understand why companies don't switch to ADA. The majority (all?) of these problems disappear.
http://en.wikipedia.org/wiki/Buffer_overflow#Choice_of_programming_language
Stop, since it seems it's time for the IT industry to stop and evaluate the tools it's using to create programs.
DEP
DEP has nothing to do with digital signing.
All DEP does is turn off the "this memory contains executable code" flag in the page table (or equivalent) on the basis that program data and the stack does not typically contain CPU instructions.
Basically, it's a feature that should have been there since day 1 because the only reason you would want to execute program data is for things like self-modifying code and other hacks which aren't worth it in 99.999% of cases.
From what I understand, DEP has to be explicitly enabled in:
* The BIOS
* The OS
* The compiler when building your program
i.e. it's not on by default in many cases, presumably because there is so much utterly shite code out there (both closed and open source) which would break if it suddenly couldn't execute its own data.
Basically, it should be on by default with a clear warning when it is triggered by a crap program, explaining that the cause is either a vulnerability or shite programming (the latter has a good chance of creating many of the former anyway) and therefore the program should be fixed. If that's not possible, then the feature can of course be turned off.
a great demotivation poster says
"The purpose of your life could be only to serve as a warning to others." The poster then shows a ship wreck in shallow waters. Lets be honest for Adobe it is far too late. That boat sailed when earlier this decade they decided to outsource their code base to lowest bidder code monkeys in India. The cost to refactor and fix their badly broken code would be astronomical (how the hell their broken products became stardard-like on the internet is beyond me). Adobe though should be warning to the mega corporations that once you start down the rabbit hole it is really tough to dig your way back out.

IT infrastructure monitoring strategies
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Data control in the cloud
Cloud based data management
Agentless Backup is Not a Myth