As a hardware capability of modern processors this addition is important, but its use depends entirely upon support from the operating system. So when Microsoft introduced support for this into their operating systems, they termed it Hardware DEP for Data Execution Prevention. Support for hardware DEP was introduced into the 32-bit versions of Windows XP with Service Pack 2, into Windows 2003 Server with Service Pack 1, and has always been present in Windows Vista. Unfortunately, however, in every case, hardware DEP support is disabled for all or most of the system’s software by default. It does no one any good unless it’s turned on.
When hardware DEP support is active, an XD/NX-aware operating system running on an XD/NX-capable and enabled processor will mark all memory regions not explicitly containing executable code as non-executable. This protects the system’s “heaps”, “stacks”, data and communications buffers from inadvertently running any executable code they might contain.
Why would data or communications buffers ever contain executable code? . . . because so-called “Buffer Overrun” attacks are the predominant way Internet-connected computers have historically been remotely hacked and compromised. Hackers locate obscure software vulnerabilities which allow them to “overrun” the buffers with their own data. This tricks the computer into executing the hacker’s supplied data (which is actually code) contained within that buffer. But if the operating system has marked that Internet communications buffer region of memory as only being valid for containing data and NOT code, the hacker’s attack will never get started. Instead, the operating system will display a notice to the user that the vulnerable program is being terminated BEFORE any of the hacker’s code has the chance to run.
from UNKNOWN vulnerabilities in the system and user programs.
Anti-Virus and anti-malware software is useful, but as we know, virus signature files must be continually updated to keep A/V software aware of new threats. Significantly, A/V software is unable to protect against unknown viruses and malware intrusions because it searches for known malicious code rather than detecting and blocking potentially malicious behavior. Hardware DEP, on the other hand, when properly configured, hardens the entire system against both known and unknown vulnerabilities by detecting and preventing the behavior of code execution in data buffers.
Buffer overrun vulnerabilities are so difficult to prevent that scores of them are being found and exploited in operating system and application software every day. Taking advantage of modern processor XD/NX capabilities is a powerful way to fight back and prevent this most common class of Internet vulnerabilities.
“SecurAble” concerns itself with the capabilities and current state of the system’s processor. So in the case of support for hardware DEP, SecurAble informs its user whether their system has the capability of enabling and supporting this most significant and important capability. But that’s all SecurAble was designed to do. Our follow-on security freeware “DEPuty” will focus on helping users whose machines are hardware DEP capable to choose and configure among Windows several modes of DEP support, then to test and verify their system’s operation and support of hardware DEP. This is important because, by default, Windows operating systems do NOT take advantage of hardware DEP capabilities due to the likelihood of false alarms caused by non-malicious programs and drivers that are not “DEP friendly.”
If you wish to explore the use of hardware DEP with your Windows XP/SP2 or Vista system immediately, without waiting for our hand-holding DEPuty utility, Microsoft’s article Knowledge base article 875352: “A detailed description of the Data Execution Prevention (DEP) feature in Windows XP Service Pack 2, Windows XP Tablet PC Edition 2005, and Windows Server 2003” explains hardware DEP’s various modes and provides guidelines for enabling it on your system:
64-bit-capable processors have the ability to run the 64-bit versions of Microsoft’s substantially more secure XP, Windows 2003, and Vista operating systems. Those operating systems are more secure because Microsoft, having learned many lessons from mistakes in the past, made the firm decision to lock-down their 64-bit OS kernels. The 64-bit Windows kernels actively police themselves to guard against many rootkit-style and other kernel attacks that have caused so many problems for users of the 32-bit Windows operating systems.
These advanced kernel-protection technologies cannot be ported back into current or even future versions of Microsoft’s 32-bit operating systems because doing so would “break” so many existing programs and drivers as to make the system impossible to use. Microsoft knows that one day the personal computing industry will have moved over to 64-bit operating systems much as we all once moved from the 16-bit based systems to 32-bits.
SecurAble indicates by displaying either a “32” or a “64” whether the system’s processor has the 64-bit instructions or extensions necessary to run 64-bit versions of Microsoft’s present and future operating systems.
As was mentioned in the boxes above, hardware support for DEP is the single most exciting and potentially powerful technology for detecting, blocking, and preventing all manner of exploitation of “unchecked buffer” buffer overruns in Windows. Hardware-enforced DEP is the malicious hacker’s worst nightmare since it has the potential to catch and stop nearly all Internet-style remote communications buffer overflow attacks.
“Virtual Machine” technology is used to create fully contained environments that can be used to insulate the real hosting operating system from any actions taken by software running within the “virtual” environment. Although this security benefiting virtual machine technology has been used for many years, its widespread adoption has been slowed down by the significant performance overhead imposed by software emulation of the virtual environment. Intel’s and AMD’s native hardware support for virtual machines means that virtually all of this emulation overhead can be eliminated from both the host and virtual environments. This makes the use of virtual machines for security containment much more practical.
The second benefit of hardware support is that even malicious software running with maximum privileges in the system’s kernel is unable to escape from virtual containment. Thus, hardware support for virtual machine technology introduces the possibility of creating a “hypervisor” to operate at a hardware-enforced level below the operating system “supervisor” which opens many exciting possibilities for further enhancing the system’s security. It will likely be several years before these capabilities are offered natively within Windows, but we might expect to see third-party security software publishers taking advantage of these features in the near future.