Role in IT decision-making process:Align Business & IT GoalsCreate IT StrategyDetermine IT NeedsManage Vendor RelationshipsEvaluate/Specify Brands or VendorsOther RoleAuthorize PurchasesNot Involved

Work Phone:

Company:

Company Size:

Industry:

Street Address

City:

Zip/postal code

State/Province:

Country:

Occasionally, we send subscribers special offers from select partners. Would you like to receive these special partner offers via e-mail?YesNo

Your registration with Eweek will include the following free email newsletter(s):News & Views

By submitting your wireless number, you agree that eWEEK, its related properties, and vendor partners providing content you view may contact you using contact center technology. Your consent is not required to view content or use site features.

By clicking on the "Register" button below, I agree that I have carefully read the Terms of Service and the Privacy Policy and I agree to be legally bound by all such terms.

A study by Secunia finds that many popular third-party applications, such as Sun Java JRE, Apple QuickTime and Google Picasa, are not taking advantage of the protections offered by two security features built into Microsoft Windows.

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.

Further reading

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.