Differences between current version and previous revision of BufferOverflow.
Other diffs: Previous Major Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 2 | Last edited on Sunday, March 7, 2004 3:05:08 pm | by AristotlePagaltzis | |
| Older page: | version 1 | Last edited on Sunday, March 7, 2004 2:16:13 am | by PerryLorier | Revert |
@@ -1,5 +1,7 @@
-Buffer overflows are
when you read more
data into a buffer than it can hold
, normally
overwriting the data of
whatever the next thing
is in memory.
This has been exploited to great effect in recent years due to sloppy C/C++ coding.
+A BufferOverflow can occurs
when a program copies input
data without checking its length
into a buffer that's too short for the input in question
, overwriting whatever is next
in memory. This has been exploited to great effect in recent years due to sloppy [
C]
/[
C++]
coding.
-The main problem with exploiting buffer overflows is that
the stack
grows "down" (ie, to lower addresses
), and you write to
buffers "upwards" (
towards higher addresses). This means that if
a buffer is stored on
the stack
, then
you can overwrite whatever else is on the stack including the
return address of a function. Thus, normally exploits are set up so when
a function returns it returns
into the address of
the buffer, and then arbitary (
usually malicious)
code can be executed
.
+Because
the [Stack]
grows towards grows lower addresses (
"down"), while
buffers are written
towards higher addresses ("upwards"
), during function calls one of the next things in memory past
a buffer usually
is the address to return to from the call. By carefully chosing the value at the right place of your input data
, you can overwrite this
return address with
a value that points
into the buffer now filled with your input
, thus causing the program to execute whatever data you provided once the function returns. Such input is
usually carefully constructed
malicious code.
-Recently there has been a great deal
of discussion about making
the stack non executable so that
this attack will fail. This however ([IMHO]) is rather pointless
, since you can just set up
the stack in
a way where it runs
a sequence
of libc functions anyway
. Admittidly
you can't do conditionals, but you can make it return into for instance
the beginning
of "system(3)"
with the parameter
"rm -rf /" on the stack where system would expect
it's argument
.
+Because
of the wide applicability of
this attack technique
, it has been studied so thoroughly that construction of exploitative input has become an almost formulaic procedure. The timespan between
the discovery of
a BufferOverflow vulnerability and creation of an exploit is rarely longer than
a day, and often a matter
of only hours
.
+
+An obvious but shortsighted counter is to mark the memory area containing the [Stack] as non-executable. The problem is that even though
you can't do conditionals this way
, the input data could still be constructed to cause execution
of arbitrary functions or a sequence thereof. F.ex, execution could
"return" into
system(3) with "rm -rf /" as a parameter
on the stack. This is only a plump example;
it is conceivable for an attacker to choose other calls so as to eg. gain access to a root shell
.
