Third-Party Windows Apps Not Using Microsoft Security Features, Researchers Find

 
 
By Brian Prince  |  Posted 2010-07-02
 
 
 

Danish security company Secunia revealed July 1 that many popular third-party Windows applications are not taking advantage of two built-in Windows security measures that could help defend against code execution attacks.

According to Secunia, applications such as Sun Java JRE, Apple QuickTime and RealPlayer are not making use of Microsoft's DEP (Data Execution Prevention) and ASLR (Address Space Layout Randomization) technologies. The report, entitled DEP/ASLR Implementation Progress in Popular Third-Party Windows Applications, (PDF) analyzed the way 16 popular applications use-or don't use-DEP or ASLR, and whether that has changed over time.

DEP was first added to Windows in Windows XP Service Pack 2 in August of 2004, and prevents applications from executing code from a nonexecutable memory region. Microsoft added ASLR to Windows Vista in 2007. ASLR randomizes memory space to lower the chance of an attacker successfully executing code.

"DEP and ASLR make it harder and in some cases impossible to exploit certain vulnerabilities," explained Thomas Kristensen, chief security officer of Secunia.

Though some developers have made their applications compatible with DEP over time-as is the case with Adobe Reader, for example-overall adoption has been slow and uneven between operating system versions. ASLR support, on the other hand, is improperly implemented by almost all vendors, allowing return-into-libc techniques to likely succeed in their applications or in browsers designed to otherwise be ASLR-compliant, the researchers wrote.

Kristensen said he was not sure why adoption of the technologies has been slow.

"There is no obvious answer; the technologies are well documented, DEP has been around since XP SP2 and ASLR since Vista," he said. "It is probably due to general lack of awareness and understanding amongst developers and managers in many of these companies."

He added, "Another reason may be that they don't understand the need for DEP and ASLR in all code [libraries] used-one library not using DEP/ASLR will in many cases void the efforts."

Kristensen said he expects that adoption of the technologies will increase in the future.

"While it isn't a replacement for writing proper secure code ... DEP/ASLR can certainly save them in many cases," he said.

Rocket Fuel