Note that you can also use the same
boot.ini /NoExecute= switch with other
values to turn DEP on and to set the DEP
protection level. Table 1 shows all the /
NoExecute values.
The boot.ini file is available only on XP
and Windows 2003, and you can edit it using
Notepad or going to the Startup and Recovery section in System properties.
On Vista and Server 2008, the boot.ini
has been replaced by the Boot Configuration
Data (BCD) file. To edit the BCD file, Microsoft
provides a command-line utility called
bcdedit.exe.
When you run bcdedit without switches,
it shows your current boot configuration. Figure 4 shows the result of running bcdedit
on a Vista system. Note the last line that
holds the nx configuration OptIn. To change
the nx configuration to alwaysoff, you would
run the following bcdedit command:
bcdedit /set nx alwaysoff
The values specified in Table 1 for the
boot.ini /NoExecute= switch are also available
for the BCD nx option.
For more information about Microsoft
DEP and how to configure it, consult the
Microsoft article at support.microsoft.com/kb/875352/en-us.
Address Space Layout
Randomization
Another technique often used by bufferoverrun–
based malware is to inject a system
memory path that points to the location of
an important system DLL into another program’s
buffer. The malware then tricks the
program into calling that particular system
file to let the malware leverage the system
DLL’s services without being detected.
This type of buffer-overrun attack is relatively
easy to carry out if the OS always loads
certain system DLLs on the exact same
memory location. On XP, for example, the
memory locations of system DLLs are always
identical— they vary only slightly depending
on the service pack status of the system.
The new Vista and Server 2008 ASLR feature
makes it harder for malware to leverage a
system DLL’s services by randomizing DLL’s
memory location. Unlike DEP, ASLR isn’t
available on earlier Windows versions.
Each time a Vista and Server 2008 system
reboots, ASLR randomly assigns system code
(basically system DLLs and executables) to
different memory locations. This means that
the system code’s entry points (the addresses
the malware would use to call on the service
of a particular piece of system code) are in
unpredictable locations. In Vista and Server
2008, a DLL or executable can be loaded into
any of 256 locations. This
means that an attacker has
a 1/256 chance of getting
the address right. As such,
ASLR also makes it harder
for hackers to write repeatable
code such as worms
that target identical system
resources on many different
systems.
You can observe the
effect of ASLR by using
the SysInternals Process
Explorer tool, which you
can download at www.microsoft.com/technet/sysinternals/utilities/processexplorer.mspx. To
use the tool, start Process
Explorer and ensure that
you have selected the
Show Lower Pane option
in the View menu.
Then select the
explorer.exe process in the
upper pane and check the
base address of the ntdll.
dll in the base column in
the lower pane. (If you
don’t see the base column
you can add it by using the
View / Select Columns…
menu option—the Base
column can be added
from the DLL tab.)
Write down the base
address, then reboot your
system. On an XP system,
the base address for ntdll.
dll remains identical after a
system reboot (XP doesn’t
support ASLR). On a Vista
system, the base address
is different after a system
reboot (because Vista supports
ASLR).
Figure 5 shows the Process Explorer interface
and the base address for the ntdll.dll
DLL. Table 2 shows the base addresses I
found for the ntdll.dll and user32.dll DLLs
when running Process Explorer on an XP SP2
system and on a Vista system.
Continue on Page 4
