Executive Summary:
Two malware protection defenses in Vista and Server 2008 can help you protect against buffer-overrun–based attacks. They are Data Execution Protection (DEP) and Address Space Layout Randomization (ASLR). DEP and ASLR each use a slightly different proactive defense approach as a buffer-overrun defense. Where ASLR makes it more difficult for malware to find the right code, DEP makes it more difficult for malware to execute the code once the target code is found. You can leverage both techniques at the same time and they can also be leveraged in virtual computing environments such as Microsoft Virtual PC or VMware products.
|
Attacks based on buffer overruns (aka buffer
overflows) have been a problem for a long time
and are still considered one of the computer
industry’s most important security problems. The first
buffer-overrun–based attack distributed via the Internet,
the Morris worm, did a lot of harm in 1988. The sad
thing is that the creators of the Morris worm didn’t write
the worm to cause harm but rather as an experiment for
measuring the size of the Internet. The Morris worm
exploited weak passwords and known vulnerabilities
in UNIX programs such as sendmail and Finger. Two
recent well-known attacks that involved exploiting buffer
overruns, the Code Red and SQL Slammer worms,
exposed many Internet-connected systems to attackers’
control. In 2001, the Code Red worm exploited a bufferoverrun
vulnerability in Microsoft Internet Information
Services (IIS) 5.0 (the IIS version that is bundled with
Windows 2000), and in 2003, the SQL Slammer worm
used a buffer-overrun vulnerability to compromise
machines running Microsoft SQL Server 2000.
You can defend against buffer-overrun–based attacks
by using defenses that Microsoft includes in Windows
Vista and Windows Server 2008: Data Execution Prevention
(DEP) and Address Space Layout Randomization
(ASLR). (At the time of this writing, Microsoft was about to
release Vista SP1 and had released Windows Server 2008
RC0.) I’ll explain why these defenses are important and
how you can configure them and observe their behavior.
Understanding Buffer Overruns
Before going into more detail on the Vista and Server 2008
buffer-overrun defenses, it might be worthwhile to look
at how a buffer overrun works and how it can harm your
systems and data.
A buffer overrun occurs when a malicious or badly
engineered program stores data beyond the boundaries
of a fixed-length buffer in computer memory. The result
is that the extra “overflowing” data overwrites adjacent
memory locations. The data that’s overwritten can
include other buffers, variables, and program logic and
may cause a process to crash or produce incorrect results.
An even bigger threat is that the injected data often
includes executable code that the program under attack
is then lured to execute. This executable code often contains
the real payload of a buffer-overrun–based attack.
It’s used to steal or delete data, create Denial of Service
(DoS)–based service outages, trigger privilege elevations,
or spread malware to other systems.
Figure 1 gives a simple example of a buffer overrun.
A program has defined two variables that are stored in
adjacent memory locations. The first variable is an eightbyte-
long string called X; the second, a two-byte integer
called Y. Initially, X contains nothing but zero bytes, and
Y contains the number 30. Imagine that a user (whether
unintentionally or maliciously) inputs a character string
OVERFLOW to this program. The program then attempts
to store this character string in X’s memory location
followed by a 0 value to mark the end of the string. The
program logic doesn’t check the length of the string
and partially overwrites the value of Y. The result is that,
although the programmer didn’t intend to change the
value of Y when variable X receives input, variable Y’s
original value 30 is now replaced by the number that’s
part of the character string that was injected into the variable
X memory location.
Developers can prevent buffer overruns by including
sufficient boundary checks in their program code and by
leveraging compilers or runtime services that perform
boundary checks. Boundary checks ensure that input
data are of the right length. Although boundary checking
and enforcement have become best practices for developers,
plenty of legacy code doesn’t include boundary
checks. Also, coding best practices are worthless if some
programmers don’t follow them.
These reasons explain why many hardware, application,
and OS software vendors including Microsoft have
developed proactive defenses that attempt to stop bufferoverrun
attacks in badly engineered code. Let’s look at
Microsoft’s implementations of DEP and ASLR.
Data Execution Protection
As I mentioned above, buffer-overrun–based attacks
often write executable malicious code to another
program’s memory buffers and then trick the program
into executing the malicious payload. You can
tackle the execution of maliciously injected code
by using DEP. DEP lets Windows mark memory locations that should only contain data as
non-executable (NX). When an application
attempts to execute code from NX-marked
memory locations, Windows’ DEP logic will
block the application from doing so.
A negative side effect of the buffer-overrun
protection offered by DEP is that the
blocked application will typically halt. In
other words, even though DEP stops malware
from executing its malicious payload,
this situation creates a new opportunity for
malware to launch DoS attacks.
Microsoft includes DEP support not only
in Vista and Server 2008, but also in Windows
XP SP2, Windows Server 2003 SP1, Windows
2003 R2. Microsoft DEP implementation
comes in two flavors: hardware-enforced
DEP and software-enforced DEP.
Hardware-enforced DEP. Hardwareenforced
DEP leverages a processor feature
that AMD refers to as the no-execute pageprotection
(NX) feature and that Intel refers
to as the Execute Disable Bit (XD) feature. At
the time of writing, AMD supported NX only
on its 64-bit processors, and Intel supported
XD only on the Itanium and EM64T 64-bit
processors and a small number of 32-bit
Prescott processors. Microsoft is not the only
OS vendor that leverages the NX and XD
processor features for stopping buffer overruns:
NX- and XD-enabled software is also
available in other OSs such as Linux and
UNIX BSD (see en.wikipedia.org/wiki/Nx-bit
for more information).
Software-enforced DEP. Softwareenforced
DEP lets Microsoft provide DEP on 32-bit processor systems
not equipped with an NX- or
XD-compatible processor. In
this software workaround, the
processor-level NX- or XD-bit
functionality is provided by a set
of special pointers that the Windows
OS automatically adds to
data objects stored in the system
memory.
Continue on Page 2
Previous
Register
