GRC | SecurAble: Determine Processor Security Features |

https://www.grc.com/securable.htm

Page last modified: Jan 31, 2012 at 07:29

Developed by Steve Gibson

Modern processors incorporate features beneficial to security. SecurAble displays the status of the three most significant security-related processor features:

File stats for: SecurAble

Last Updated: Size: 115k Jan 14, 2007 at 11:14 (2,544.11 days ago) Downloads/day: 870 Total downloads: 2,941,136 Current Rank: 2 Historical Rank: 4

SecurAble probes the system's processor to determine the presence, absence and operational status of three modern processor features: 64-bit instruction extensions, Hardware support for detecting and preventing the execution of code in program data areas, ... and Hardware support for system resource virtualization.

Hardware D.E.P., NX, XD & EVP

Modern processor hardware can be instructed to designate regions of memory as non-executable. This means that the memory can be used to store reference data to be read and written, but that the processor cannot treat the contents of the memory as program code to be directly executed. Intel calls this capability in their newer processors XD for eXecute Disable and AMD refers to it as NX for No eXecute. AMD's marketing materials also sometimes refer to this capability by the annoying

1 de 8

01/01/2014 23:03

GRC | SecurAble: Determine Processor Security Features | marketing term EVP for Enhanced Virus Protection.

https://www.grc.com/securable.htm

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.

The real beauty of this system is that it provides strong protection 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

2 de 8

01/01/2014 23:03

GRC | SecurAble: Determine Processor Security Features | back and prevent this most common class of Internet vulnerabilities.

https://www.grc.com/securable.htm

DEPuty our next security freeware

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: http://support.microsoft.com/kb/875352

How do 64-bit instructions help with security? 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. How does Hardware DEP help with security? 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. Hardwareenforced 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. How does Hardware Virtualization help with security? 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

3 de 8

01/01/2014 23:03

GRC | SecurAble: Determine Processor Security Features |

https://www.grc.com/securable.htm

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.

Running SecurAble
SecurAble does not require any setup or installation. The executable file can simply be run as a stand-alone Windows or Linux/Wine program. And nothing is left behind in the system after the executable file is deleted. SecurAble "runs clean" and makes no changes to the system registry or file system. This makes it ideal for quickly running on any system for example at a computer retailer where you want to determine which security-helping features the system's processor includes. SecurAble includes a built-in kernel-mode module that empowers it to determine with enhanced accuracy which features of the processor may be present, and whether any features have been disabled or suppressed by previous actions of the system's BIOS or operating system. It is not necessary to run SecurAble with administrative privilege, but when SecurAble is run without the administrative privileges required to run code in the kernel, it may indicate that it cannot be certain of its findings. In such cases, re-running SecurAble with administrative privilege will empower it to determine the system's capabilities with complete accuracy. Once SecurAble is running and displaying its findings, you are encouraged to click on each of the three display sections to view specific context-sensitive information about what SecurAble has determined for each processor characteristic:

4 de 8

01/01/2014 23:03

GRC | SecurAble: Determine Processor Security Features |

https://www.grc.com/securable.htm

SecurAble declares its possible need to run kernel-mode code to Windows Vista UAC (User Account Control) system. Therefore, Vista users will be asked to permit this whenever SecurAble is started under Vista.

SecurAble's Results
Clicking on each of the three regions of SecurAble's display to obtain additional contextual information about each feature should provide all of the help you'll need to understand what's going on in any system SecurAble encounters. GRC's newsgroup community extensively tested SecurAble throughout its pre-release development. We were delighted to discover that SecurAble would sometimes inform its user of capabilities they were not aware their systems possessed. This would often trigger a search through their system's BIOS configuration screens to uncover BIOS settings which had previously escaped notice. And something similar happened to me: As you can see from the image to the left (click for full size) I discovered that my HP TC1100 TabletPC contains a Pentium M processor with hardware DEP capabilities. The only problem was that SecurAble was displaying "OFF" for DEP, indicating that although the processor offered hardware DEP support, something had disabled it. That "something" could only be the system's BIOS. So I went searching through the TC1100's BIOS screens for some way to enable the processor's support for hardware DEP . . . but there no mention of it in the BIOS. Other pre-release testers in our newsgroups were reporting the same thing, so I knew that SecurAble would not be the last hardware DEP-related freeware emerging from this work. Controlling processor features that have been neglected by systems' BIOSes will be one of the capabilities we will be exploring and developing in the follow-on DEPuty utility.

5 de 8

01/01/2014 23:03

GRC | SecurAble: Determine Processor Security Features |

https://www.grc.com/securable.htm

SecurAble and Security Now!

Those of you who have discovered SecurAble through listening to my weekly Security Now! MP3 audio netcast with Leo Laporte will probably already know of our netcasts during November and December of 2006 during which we discussed Windows Vista Security, Vista's Kernel Patch Protection, and the development of this SecurAble security-related freeware. If you have not listened to those standard-format MP3 audio files you may find their content interesting, informative, and useful. They are all available in higher-quality 64 kbps MP3 format, as smaller-size 16 kbps MP3 format, and also as printed text, web page, and PDF file transcripts. These links will jump you directly to each section of the main Security Now! audio netcast listing page: Episode #66 Windows Vista Security Episode #67 Kernel Patch Protection Episode #71 SecurAble

F.A.Q.

Q:

Okay Gibson. If hardware DEP brings such amazing benefits to personal computers, why didn't it catch-on immediately after Microsoft released XP's Service Pack 2, and why doesn't Microsoft always have it enabled by default? There are two reasons: Hardware support and backward compatibility. Hardware Support: At the time of DEP's initial appearance in Service Pack 2 of Windows XP, only a few recent AMD processors and Intel's advanced Itanium processors offered the XD/NX capability. (None of Intel's mainstream Pentium-line processors did.) Many of the documents you'll find on the web continue to refer to these processors as the only ones supporting the XD/NX feature required for hardware DEP. Fortunately, that situation did not last long. Because hardware DEP has such tremendous potential for hardening systems against the exploitation of data buffer vulnerabilities, every Intel and AMD processor being made since 2005 includes XD/NX support. SecurAble was created to let users know whether the systems they already have might be hardware DEP-capable. Backward Compatibility: Although hardware DEP is extremely cool, it significantly changes the way systems have traditionally operated. Even though programs have no need to execute code from memory buffers marked as containing data, many do, because doing so was never frowned upon or prohibited by the system. So those programs will cause some problems in any system with active and enforced hardware DEP. As an interim measure, Microsoft create per-program OptOut and OptIn policies to create exceptions so that a Windows system that is trying to enforce DEP can tolerate a few misbehaving programs. The hope is that authors of DEP-incompatible programs will receive some feedback pressure from their users and clean up their code . . . which is easily done.

A:

Q:

Does Hardware DEP provide perfect protection against any and all possible buffer overrun style vulnerabilities and exploits? No. But, in the jargon of security researchers, it dramatically reduces the attack surface of any system using it. After hardware DEP support was introduced into Windows XP the hacker community jumped on it and spent a

A:

6 de 8

01/01/2014 23:03

GRC | SecurAble: Determine Processor Security Features |

https://www.grc.com/securable.htm

great deal of time trying to find ways to bypass DEP's inherently strong protection. Some clever schemes have been developed and described to, for example, use some of the system's existing code to achieve some remote exploitation of the system. However, hardware DEP raises the protection bar so high that hackers have only been able to support empty claims of DEP's not perfect. In the words of one well known security vulnerability researcher, in his white paper titled Buffer Underruns, DEP, ASLR and improving the Exploitation Prevention Mechanisms (XPMs) on the Windows platform (PDF) David Litchfield concludes: Finally, it's important to note that whilst there may occasionally be routes through to arbitrary code execution, having these protection mechanisms is far better than not having them. This paper should not be taken as a criticism of any of the exploit prevention mechanisms but rather a demonstration of how the possibilities for successful code execution exploits are rapidly disappearing. David writes that ...the possibilities for successful code execution exploits are rapidly disappearing. That's certainly true, but it's largely the presence of the new hardware DEP capability, when enabled and operating, that makes this true.

Q: A:

If hardware DEP isn't perfect then what good is it? Why is it worth the hassle? Life would be much simpler if security could be black and white and we could be 100% secure. But security is not black and white and we cannot be 100% secure. We lock our front doors, but we still have glass windows. But having glass windows does not mean that it's not still worthwhile to lock our front doors. The best security is obtained through removing the easiest means of penetration and making security breaches more difficult, expensive, and less likely to succeed. It is extremely unfortunate, though completely understandable, that Microsoft chose to set Windows XP's DEP support, by default, to OptOut. It's unfortunate because this only protects some of Microsoft's operating system programs, but no programs that the user may be running. It's understandable because Microsoft could only guarantee that their own code would be DEP-compatible and it would have been disastrous if the installation of XP's very beneficial Service Pack 2 caused failures in third-party Windows applications. The good news is that you can take direct responsibility for the security of the systems over which you have some control by experimenting with hardware DEP and enabling it to the highest level possible. Your system will then be virtually immune from the most common means of remote malicious exploitation.

Q:

For Hardware D.E.P., SecurAble is indicating OFF? (OFF with a question mark). What does that mean? Intel and AMD processors provide the means for masking the presence of their XD and NX capabilities from application code running in user-mode. But the operating system is always able to determine the truth. Since application software can be misled into believing that processor features are not present, SecurAble contains operating system kernel-mode code that it attempts to load in order to determine the complete truth about the processor's features. But since SecurAble's code is 32-bit Windows kernel code, SecurAble is only able to obtain this additional information when it is run with administrative

A:

7 de 8

01/01/2014 23:03

GRC | SecurAble: Determine Processor Security Features |

https://www.grc.com/securable.htm

privilege on 32-bit versions of Windows NT, 2000, XP, or Vista. SecurAble won't be able to run its kernel-mode code under any 64-bit operating system, under Linux with WINE emulation, or if it doesn't have administrative privileges. So if SecurAble displays OFF? it believes that the system may have hardware DEP capabilities that are being suppressed by the BIOS or the operating system, but that it is unable to verify this due to the limitations of the environment in which is it running. As always, you may click on the OFF? result image to learn more about what SecurAble has found and what it recommends to obtain a definitive result.

Getting Involved
As you will have detected if you've read through this entire page, what we learned during the development of SecurAble has led us down a significant path. SecurAble has turned out to be just phase one of the work needed for the full deployment of hardware DEP on Windows systems to dramatically enhance the functional security and robustness of Windows XP, 2003, and Vista. All three of those OS versions are able to support hardware DEP when it is properly configured in the system's BIOS, hardware, and Windows . . . and in doing so they are able to detect, block, and completely prevent the most common form of remote Internet communications exploitation: Buffer Overflows. The GRC newsgroup community will soon be embarking on the research and development of DEPuty, our follow-on, significantly more capable DEP-related security freeware utility. If you are interested in participating in the fun of discovery, research and development with the direct ability to influence the design of this next utility you are invited to configure your system's built-in newsgroup reader to access the GRC newsgroups . . . then join our terrific group. Our Discussions page has all the details for configuring any newsreader to participate in the GRC newsgroups.

Version History
[1.0.2570.1] 01/18/07, Initial release of SecurAble.

Gibson Research Corporation is owned and operated by Steve Gibson. The contents of this page are Copyright (c) 2013 Gibson Research Corporation. SpinRite, ShieldsUP, NanoProbe, and any other indicated trademarks are registered trademarks of Gibson Research Corporation, Laguna Hills, CA, USA. GRC's web and customer privacy policy. Last Edit: Jan 31, 2012 at 07:29 (701.27 days ago) Viewed 814 times per day

8 de 8

01/01/2014 23:03