没有合适的资源?快使用搜索试试~ 我知道了~
一部详细介绍缓冲区溢出的资料,对安全感兴趣的朋友可以下来作为参考
资源推荐
资源详情
资源评论
Abstract
Buffer overflows have been the most common
form of security vulnerability for the last ten
years. More over, buffer overflow vulnerabilities
dominate the area of remote network penetra-
tion vulnerabilities, where an anonymous Inter-
net user seeks to gain partial or total control of
a host. If buffer overflow vulnerabilities could
be effectively eliminated, a very large portion of
the most serious security threats would also be
eliminated. In this paper, we survey the various
types of buffer overflow vulnerabilities and
attacks, and survey the various defensive mea-
sures that mitigate buffer overflow vulnerabili-
ties, including our own StackGuard method. We
then consider which combinations of techniques
can eliminate the problem of buffer overflow
vulnerabilities, while preserving the functional-
ity and performance of existing systems.
1 Introduction
Buffer overflows have been the most common form
of security vulnerability in the last ten years. More over,
buffe r overflow vulnerabilities dominate intheareaof
remote network penetration vulnerabilities, where an
anonymous Internet user seeks to gain partial or total
control of a host. Because these kinds of attacks enable
anyone to take total control of a host, they represent one
of the most serious classes security threats.
Buffer overflow attacks form a s ubstantial portion
of all security a ttacks simply because buffer overflow
vulnerabilitiesaresocommon[15]andsoeasyto
exploit [30, 28, 35, 20]. However, buffer overflow vul-
nerabilities particularly dominate in the c lass of remote
penetration attacks because a buffer overflow vulnera-
bility presents the attacker with exactly what they need:
the ability to inject and execute attack code. The
injected attack code runs with the privileges of the vul-
nerable program, and allows the attacker to bootstrap
whatever other functionality is needed to control
(“own” in the underground vernacular) the host com-
puter.
For instance, among the five “new” “remote to
local” attacks used in the 1998 Lincoln Labs intrusion
detection evaluation, three were essentially social engi-
neering attacks that snooped user credentials, and two
were buffer overflow s. 9 of 13 CE RT advisories from
1998 involved buffer overflows [34] a nd at least half of
1999 CERT advisorie s involve buffer overflows [5]. An
informal survey on the Bugtraq security vulnerability
mailing list [29] showed that approximately 2/3 of
respondents felt that buffer overflows are the leading
cause of security vulnerability.
1
Buffe r overflow vulnerabilities and attacks c ome in
a variety of forms, which we describe and classify in
Section 2. Defenses against buffer overflow attacks
similarly come in a variety of forms, which we describe
in Section 3, including which kinds of attacks and vul-
nerabilities these defenses a re effective against. The
Immunix project has developed the StackGuard defen-
sive mechanism [14, 11], which has been shown to be
highly e ffective at resisting attacks without compromis-
ing system compatibility or performance [9]. Section 4
discusses which combinations of defenses complement
each other. Section 5 presents our conclusions.
2 Buffer Overflow Vulnerabilities and
Attacks
The overall goal of a buffer overflow attack is to
subvert the function of a privileged program so that the
attacker can take control of that program, and if the pro-
gram is sufficiently privileged, thence control the host.
Typically the attacker is attacking a root program, and
immediately executes code similar to “exec(sh)” to get
a root shell, but not always. To achieve this goa l, the
attacker must achieve two sub-goals:
Buffer Overflows:
Attacks and Def enses for the Vulnerability of the De ca de
*
Crispin Cowan, Perry Wagle, Calton Pu,
Steve Beattie, and Jonathan Walpole
Department of Computer Science and Engineering
Oregon Graduate Institute of Science & Technology**
(crispin@cse.ogi.edu)
http://www.cse.ogi.edu/DISC/projects/immunix
*. This work supported in part by DARPA grant F30602-96-1-
0331, and DARPA contract DAAH01-99-C-R206.
**Of these authors, Crispin Cowan, Steve Beattie, and Perry
Wagle are now with Immunix, Inc., and Calton Pu is at
Georgia Tech.
AlsopresentedasaninvitedtalkatSANS2000(System
Administration and Network Security), http://
www.sans.org/newlook/events/sans2000.htm
1.The remaining 1/3 of respondants identified
“misconfiguration” as the leading cause of security
vulnerability.
Proceedings of the Foundations of Intrusion Tolerant Systems (OASIS’03)
0-7695-0490-6/99 $17.00 1999 IEEE Previously published in the DARPA Information Survivability Conference and Exposition 2000 Proceedings
1. Arrange for suitable code to be available i n the pro-
gram's a ddress space.
2. Get the program to jump to that code, with suitable
parameters loaded into registers & memory.
We categorize buffer overflow attacks is in terms of
achieving these two sub-goals. Section 2.1 describes
how the attack code is placed in the victim program’s
address space (which is whe re the “buffer” part comes
from). Section 2.2 describes how the attacker overflows
a program buffe r to a lter adjacent program state (which
is where the “overflow” part comes from) to induce the
victim program to jump to t he attack code. Section 2.3
discusses some issues in co mbining the co de injection
techniques from Section 2.1 with the control flow cor-
ruption te chniques from Section 2.2.
2.1 WaystoArrangeforSuitableCodetoBein
the Program's Address Space
There are two ways to arrange for the a ttack c ode to
be in the victim program’s address space: either inject
it, or use what is already there.
Inject it: The attacker provides a s tring as input to the
program, which the program stores in a buffer. T he
string contains bytes that are actually native CPU
instructions for the platform being attacked. He re
the attacker is (ab)using the victim program’s buff-
ers to store the a ttack code. Some nuances on this
method:
• The attacker does not have to overflow any buff-
ers to do this; sufficient payload can be injected
into perfectly reasonable buffers.
• The buffer can be located anywhere:
• onthestack(automaticvariables)
• on the heap (mal loc’d variables)
• in the static data area (initialized or uninitial-
ized)
It is already there: Often,thecodetodowhatthe
attacker wants is already present in the program’s
address space. The attacker need only parameterize
the code, a nd then cause the program to jump to it.
For instance, if the attack code needs to execute
“exec(“/bin/sh”)”, and there exists code in
libc that executes “exec(arg)” where “arg” is a
string pointer argument, then the a ttacker need only
change a pointer to point to “/bin/sh”andjump
to the appropriate instruc tions in the libc library
[41].
2.2 W ays to Cause the Program to Jump to the
Attacker's Code
All of these methods seek to alter the program’s
control flow so that the program will jump to the attack
code. The basic method is to overflow a buffer that has
weak or non-existent bounds checking on its input with
a goal of corrupting the state of an adjacent part of the
program’s state, e.g. adjacent pointers, etc. By over-
flowing the buffer, the attacker can overwrite the adja-
cent program state with a near-arbitrary
2
sequence of
bytes, resulting in an arbitrary bypass of C’s type sys-
tem
3
and the victim program’s l ogic.
The classification here is the kind of program state
that the attacker’s buffer overflow seeks t o c orrupt. In
principle, the corrupted state can be any kind of state.
For instance, the original Morris Worm [37] used a
buffe r overflow against the fingerd program to cor-
ruptthenameofafilethatfingerd would execute. In
practice, most buffer overflows found in “the wild”
seek to corrupt code pointers: program state that points
at code. The distinguishing factors among buffer over-
flow attacks is the kind of state corrupted, and where in
the memory layout the state is located.
Activation Records: Each time a function is called, it
lays down an activation record on the stack [1] that
includes, among other things, the return address that
the program should jump to when the function exits,
i.e. point at the code injected in Section 2.1. Attacks
that c orrupt activation record return addresses over-
flow automatic variables, i.e. buffers local to the
function, as shown in Figure 1. By corrupting the
return address in the activation record, the attacker
causes the program to jump to attack code when the
victim function returns and dereferences the re turn
address. T his form of buffer overflow is called a
“stack smashing attack” [14, 30, 28, 35] and consti-
tute a majority of current buffer overflow attacks
Function P o inters: “void (* foo)()”declares
the variable foo which is of type “pointer to func-
tion returning void.” Function pointers can be allo-
cated anywhere (stack, heap, static data area) and so
the attacker need only find an overflowable buffer
adjacent to a function pointer in any of these a reas
and overflow it to change the function pointer.
Some time later, when the program m akes a call
through this function pointer, it will instead jump to
the attacker's desir ed location. An example of this
kind of attack appeared in an attack against the
superprobe program for Linux.
Longjmp buffers: C includes a simple checkpoint/roll-
back system called setjmp/longjmp. T he idiom is to
say “ setjmp(buffer)” to c heckpoint, and say
“longjmp(buffer)”togobacktothecheck-
point. However, if the a ttacker can corrupt the state
of the buffer, then “longjmp(buffer)”will
2.There are some bytes that are hard to inject, such as control
characters and null bytes that have special meaning to I/O
libraries, and t hus may be filtered before they reach the
program’s memory.
3.That this is possible is an indication of the weakness of C’s
type system.
Proceedings of the Foundations of Intrusion Tolerant Systems (OASIS’03)
0-7695-0490-6/99 $17.00 1999 IEEE Previously published in the DARPA Information Survivability Conference and Exposition 2000 Proceedings
jump to the attacker's code instead. Like function
pointers, longjmp buffers can be a llocated any-
where, so the attacker need only find an adjacent
overflowable buffer. An example of this form of
attack appeared against Perl 5.00 3. The at tack first
corrupted a longjmp buffer used to recover when
buffe r overflows are detected, and then induces the
recovery mode, causing the Perl interpreter to jump
to the attack code.
2.3 Combining Code Injection and Control
Flow Corruption Techniques
Here we discuss some issues in combining the
attack code injection (Section 2.1) and control flow cor-
ruption (Section 2.2) techniques.
The simplest and most common form of buffer
overflow attack combines an injection technique with
an activation record corruption in a single s tring. The
attacker locates an overflowable automatic variable,
feeds the program a large string that simultaneously
overflows the buffer to change the activation record,
and c ontains the injected attack code. This is the tem-
plate for an attack outlined by Levy [30]. Because the C
idiom of a llocating a small local buffer to get user or
parameter input is so common, there a re a lot of
instances of code vulnerable to this form of a ttack.
The injection and the corruption do not have to hap-
pen in one action. The attacker can inject code into one
buffe r without overflowing it, and overflow a different
buffe r to corrupt a code pointer. This is typically done
if the overflowable buffer does have bounds checking
on it, but gets it wrong, so the buffer is only overflow-
able up to a certain number of bytes. The attacker does
not have room to place code in the vulnerable buffe r, so
the code is simply inserted into a different buffer of suf-
ficient size.
If the attacker is trying to use already-resident code
instead of injecting it, they typically need to parameter-
ize the code. For instance, there are code fragments in
libc (linked to virtually every C program) that do
“exec(something)”where“something”isa
parameter. The attacker then uses buffer overflows to
corrupt the a rgument, and another buffer overflow to
corrupt a code pointer to point into libc at the appro-
priate code fragment.
3 Buffer Overflow Defenses
There are four basic approaches to defending
against buffer overflow vulnerabilities and attacks. The
brute force method of writing correct code is described
in Section 3.1. The operating systems approach
describedinSection3.2istomakethestorageareasfor
buffers non-executable, preventing the attacker from
injecting attack code This approach stops many buffer
overflow attacks, but because attackers do not necessar-
ily ne ed to inject attack code to perpetrate a buffer over-
flow attack (see S ection 2.1) this method leaves
substantial vulnerabilities. The direct compiler
approach described in Section 3.3 is to perform array
bounds checks on all array accesses. This m ethod com-
pletely eliminates the buffer overflow problem by m ak-
ing overflows impossible, but imposes substantial
costs. The indirect compiler approach de scribed in Sec-
tion 3.4 is t o perform integrity checks on c ode pointers
before dereferencing them. While this technique does
not m ake buffer overflow attacks impossible,itdoes
stop most buffer ove rflow attacks, a nd the attacks that it
does not stop are difficult to create, and the compatibil-
ity a nd pe rformance advantages ove r array bounds
checking are substantial, as described in Section 3.5.
3.1 Writing Cor rect Code
“To err is human, but to really foul up requires a
computer.” -- Anon. Writing correct code is a laudable
but remarkably expensive proposition [13, 12], espe-
cially when writing in a language such as C that ha s
error-prone idioms such as null-terminated strings and a
culture that fa vors performance over correctness.
Despite a long history of understanding of how to write
secure programs [6] vulnerable programs continue to
emerge on a regular basis [15]. Thus some tools and
techniques have evolved to help novice developers
write programs that are somewhat less likely to c ontain
buffer overflow vulnerabilities.
The simplest method is to grep thesourcecodefor
highly vulnerable library calls such as strcpy and
sprintf that do not check the length of their argu-
ments. Ve rsions of the C standard library have also be en
developed that complain when a program links to vul-
nerable functions like strcpy and sprintf.
Code auditing teams have appeared [16, 2] with an
explicit objective of auditing large volumes of code by
hand, looking for c ommon s ecurity vulnerabilities such
as buffer overflows and file system race conditions [7].
However, buffer overflow vulnerabilities can be subtle.
Even defensive code that uses safer a lternatives such as
Attack
code
return
address
Local
variables
buffer
FFFF
0000
Stack
Growth
String
Growth
Figure 1: Buffer Overflow Attack Against
Activation Re cord
Proceedings of the Foundations of Intrusion Tolerant Systems (OASIS’03)
0-7695-0490-6/99 $17.00 1999 IEEE Previously published in the DARPA Information Survivability Conference and Exposition 2000 Proceedings
剩余10页未读,继续阅读
资源评论
bluearies
- 粉丝: 0
- 资源: 5
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功