'Way, 'way back in the 1960s, computer designers tried out different techniques to limit how a computer executed its programs. Some should be pretty well known, like storage protection and the distinction between "kernel mode" for the operating system and "user mode" for applications. Another was data execution prevention
(aka "DEP"), where the computer distinguishes between RAM that stores instructions and RAM that stores data. If the program tries to jump into instructions stored in data RAM, the CPU aborts the program.
Fast forward to 2010. Most microprocessors were supporting DEP in the mid 1990s; a few supported it before that. OS support came more slowly. Windows as been using one form or another of this since 2004 in XP Service Pack 2. However, it doesn't matter for most major applications, because they didn't fix their code to take advantage of it. So, if they suffer a buffer overflow, there's nothing to prevent the computer from trundling off to la-la land.
Bran Krebs' blog reports on a survey of 17 major Windows applications performed by the security firm Secuina.
A half-dozen of them use DEP, including Apple iTunes and Safari (but not QuickTime). Firefox uses DEP, but OpenOffice does not. Acrobat Reader doesn't use it, but the survey doesn't comment on other Adobe products.
So there's not even a pattern: some open source projects use it, some don't. Some vendors use it for some products but not others.
The survey also looks at another Windows security measure, address space randomization
, which is used slightly less than DEP. Randomization takes different parts of the program and plunks them down in unpredictable spots in RAM. Traditionally, computers would always drop programs in a predictable location. This isn't strictly necessary in modern computers, because a program can always figure out where it resides, but it then needs help finding its randomly scattered pieces.
This technology, again, was well established in the 1960s. In an undergraduate moment of geek, I spent about a week playing with a relocating loader on an IBM 370. The program collected the bits of your program together, plonked them into RAM, and filled in the pointers so the main part could find the rest. It's really not rocket science, but it does
take some careful programming.