DEP is a keeper

Windows’ Data Execution Prevention stabs at the heart of malware and goofware

I am rooting around in the windows XP service Pack 2 Beta and delighting in all of the things it won’t let clueless users do. Microsoft’s Secure By Default must become the default configuration of desktop PCs. Bank on installing XP SP2 on every machine running Windows XP. For now at least, you must specify an Athlon 64, Opteron, or mobile Athlon 64 CPU for new PCs. AMD is first to market (Intel will follow this year) with CPU hardware that proves the adage, “Good things come in small packages.”

I’m referring to AMD’s new CPU circuitry that blocks the execution of code that’s planted where it doesn’t belong. Whoopee? Actually, yeah, this is worth celebrating. This is the first product out of the partnership of AMD, Intel, and Microsoft  to build hardware-enforced software protection into PCs. It is an optional feature that does not interfere with other operating systems.

In XP SP2, Microsoft calls this feature DEP (Data Execution Prevention). DEP is pitched as a virus blocker. That makes the concept easier to explain to non-gearheads, but all Windows users should know what DEP does, why it won’t block all types of malicious code, and why it should be part of every PC.

Incidentally, the fact that DEP doesn’t already exist surprises many PC users. Until the recent plagues of viruses, worms, Trojans, and spyware, developers and users would never allow hardware-based execution prevention. To say that Microsoft can flip bits to block the execution of code is to imply that PCs can refuse to run Linux. Now that DEP’s details are known, there shouldn’t be any fear about its use.

The buffer overflow is a popular viral vector. It makes a good illustration of the dangers of unregulated execution, the condition that DEP is designed to fix. Programs reserve memory blocks called buffers to store incoming data. The hacker intentionally sends more data to the application than one of its buffers will hold. The extra bytes overwrite the memory following the end of the buffer. If that overwritten space was occupied by code, instructions of the hacker’s choosing are executed in place of the original ones. It only takes a few machine language bytes to divert execution to a larger hunk of code that perpetrates the actual infection.

When DEP is activated, each new block of memory requested by the application is marked NX (non-executable). If malware, or well-intentioned buggy code, asks the PC to run instructions stored in NX-flagged memory, the CPU throws a fatal exception that kills the application or, if the kernel would be affected, halts Windows. Sections of memory that are approved for execution can also be flagged as write-protected.

As a technologist, I can criticize DEP for providing users with a false sense of safety. There are so many ways to infect a PC that DEP can’t prevent. Hackers can always rely on users to open executable e-mail attachments. Hackers can still trick systems into granting them administrative privileges. Hands-on access to just one machine opens up the whole network to external hackers. Also, DEP is easily disabled by the user, which some will do because DEP will break some applications. And finally, app developers can circumvent DEP with no great effort. It’s not a panacea. But I’ll take it, if just to protect my feet when I’m writing my own code. You really ought to take it, too.

From CIO: 8 Free Online Courses to Grow Your Tech Skills
Notice to our Readers
We're now using social media to take your comments and feedback. Learn more about this here.