Local stack overflow and return-into-libc (from GSK project)

Number 0x01: 03/23/2006

eZine lover (@eZine)

Published in

the bug magazine

· 19 Dec 2022

[ --- The Bug! Magazine 

                    _____ _              ___               _ 
                   /__   \ |__   ___    / __\_   _  __ _  / \ 
                     / /\/ '_ \ / _ \  /__\// | | |/ _` |/  / 
                    / /  | | | |  __/ / \/  \ |_| | (_| /\_/ 
                    \/   |_| |_|\___| \_____/\__,_|\__, \/ 
                                                   |___/ 

                      [ M . A . G . A . Z . I . N . E ] 

 
             [ Numero 0x01 <---> Edicao 0x01 <---> Artigo 0x03 ] 

 

.> 23 de Marco de 2006, 
.> The Bug! Magazine < staff [at] thebugmagazine [dot] org >

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LOCAL STACK OVERFLOW AND RETURN-INTO-LIBC (from GSK project)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

.> 12 de Marco de 2006,
.> Thyago Silva a.k.a dx/xgc < xgc [at] gotfault [dot] net >

Objective
Requisites
Introduction to Gotfault Sharing Knowledge (GSK)
Introduction to Buffer Overflow

4.1 Memory Sections
4.2 Function Calls Process (FCP)
4.3 Main Registers of the Stack
4.4 Introduction to the Stack Frame
4.5 Analysis of Vulnerable Source Code
4.6 Getting Start: Overflowing/Controlling/Executing

Conclusion
Objective
Requisites
Introduction to Returning Into Libc

8.1 Introduction to System Function
8.2 Analysis of Vulnerable Source Code
8.3 Getting Informations
8.4 Returning Into System Function
8.5 Setuid Call
8.6 Using Wrapper
8.7 Using Environment to Small Buffers
8.8 Analisys of Exploit Source C Code

Conclusion

1. Objective

Get basic knowledge of memory analysis and be able to control his flow to execute arbitrary code.

2. Requisites

Basic knowledge of C/PERL programming.

3. Introduction to Gotfault Sharing Knowledge (GSK)

GSK was created to interested users on programming security to discuss about exploitation techniques under stuff of the selected subject. The main goal consists on users to share knowledge with each one. I'll try to pass detailed informations of the selected subject, giving the chance to users that are just starting. All kind of users are welcome.

4. Introduction to Buffer Overflow

The principle of exploiting a buffer overflow is to overwrite parts of memory which aren't supposed to be overwritten by arbitrary input and making the process execute this code. To see how and where an overflow takes place, lets take a look at how memory is organized.

4.1. Memory Sections

The processes memory consists of three sections:

Code segment: Data, in this segment, are assembler instructions that the processor executes. The code execution is non-linear, it can skip code, jump, and call functions on certain conditions. Therefore, we have a pointer called EIP, or instruction pointer. The address where EIP points to always contains the code that will be executed next.
Data segment: Space for variables and static/dynamic buffers.
Stack segment: Which is used to pass data(arguments) to functions and as a space for variables of functions. The bottom(start) of the stack usually resides at the very end of the virtual memory of a page, and grows down. The assembler command PUSHL will add to the top of the stack, and POPL will remove one item from the top of the stack and put it in a register.

Process Memory Layout:

0xc0000000 --------------------- 
           |                   | 
           | env/argv pointer. | 
           |       argc        | 
           |-------------------| 
           |                   | 
           |      stack        | 
           |                   | 
           |        |          | 
           |        |          | 
           |        V          | 
           /                   / 
           \                   \ 
           |                   | 
           |        ^          | 
           |        |          | 
           |        |          | 
           |                   | 
           |       heap        | 
           |-------------------| 
           |        bss        | 
           |-------------------| 
           | initialized data  | 
           |-------------------| 
           |       text        | 
           |-------------------| 
           | shared libraries  | 
           |        etc.       | 
0x8000000  |-------------------|

4.2. Function Calls Process (FCP)

On a Unix system, a function call may be broken up in three steps:

Prolog: The current frame pointer(EBP register) is saved. A frame can be viewed as a logical unit of the stack, and contains all the elements related to a function. The amount of memory which is necessary for the function is reserved.
Call: The function parameters are stored in the stack and the instruction pointer(EIP register) is saved, in order to know which instruction must be considered when the function returns.
Epilog: The old stack state is restored(Return).

4.3. Main Registers of the Stack

The following registers are important in operation of the stack:

EIP - The extended instruction pointer. When you call a function, this pointer is saved on the stack for later use. When the function returns, this saved address is used to determine the location of the next executed instruction.
ESP - The extended stack pointer. This points to the current position on the stack and allows things to be added to and removed from the stack using push and pop operations or direct stack pointer manipulations.
EBP - The extended base pointer. This register usually stays the same throughout the execution of a function. It serves as a static point for referencing stack-based information such as variables and data in a function using offsets. This pointer usually points to the top of the stack for a function.

4.4. Introduction to the Stack Frame

A stack frame is the name given the entire stack section used by a given function, including all the passed arguments, the saved EIP and potentially any other saved registers as EBP, and the local function variables. Previously we focused on the stack. use in holding local variables; now we will go into the *bigger picture* of the stack.

To understand how the stack works in the real, we need some understanding of the Intel CALL and RET instructions.

The CALL instruction makes functions possible. The purpose of this instruction is to divert processor control to a different part of code while remembering where you need to return. To get this goal, a CALL instruction operates like this:

Push address of the next instruction after the call onto the stack. (This is where the processor will return to after executing the function)
Jump to the address specified by the call.

The RET instruction does the opposite. Its purpose is to return from a called function to whatever was right after the CALL instruction. The RET instruction operates like this:

Pop the stored return address off the stack.
Jump to the address popped off the stack.

This combination allows code to be jumped to and returned from very easily, without restricting the nesting of function calls too much.

4.5. Analysis of Vulnerable Source Code

#include <stdlib.h> 
#include <stdio.h> 
#include <string.h> 

int bof(char *string) { 

  char buffer[256]; 

  strcpy(buffer, string); 

  return 1; 
} 

int main(int argc, char *argv[]) { 

  bof(argv[1]); 
  printf("Not gonna do it!\n"); 

  return 1; 
}

We'll now check this source code following all flow of memory to demonstrate what happen with registers and stack area. After all we'll be able to exploit and execute any code.

Let's see instructions inside main function with gdb.

[xgc@trapdown:~]$ gcc --version 
gcc (GCC) 3.3.5 (Debian 1:3.3.5-13) 
Copyright (C) 2003 Free Software Foundation, Inc. 
This is free software; see the source for copying conditions.  There is NO 
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. 
[xgc@trapdown:~]$ gcc -o simple_stack simple_stack.c 
[xgc@trapdown:~]$ gdb ./simple_stack -q 
Using host libthread_db library "/lib/libthread_db.so.1". 
(gdb) disassemble main 
Dump of assembler code for function main: 
0x080483e9 <main+0>:    push   %ebp 
0x080483ea <main+1>:    mov    %esp,%ebp 
0x080483ec <main+3>:    sub    $0x8,%esp 
0x080483ef <main+6>:    and    $0xfffffff0,%esp 
0x080483f2 <main+9>:    mov    $0x0,%eax 
0x080483f7 <main+14>:   sub    %eax,%esp 
0x080483f9 <main+16>:   mov    0xc(%ebp),%eax 
0x080483fc <main+19>:   add    $0x4,%eax 
0x080483ff <main+22>:   mov    (%eax),%eax 
0x08048401 <main+24>:   mov    %eax,(%esp) 
0x08048404 <main+27>:   call   0x80483c4 <bof> 
0x08048409 <main+32>:   movl   $0x8048534,(%esp) 
0x08048410 <main+39>:   call   0x80482d8 <_init+56> 
0x08048415 <main+44>:   mov    $0x1,%eax 
0x0804841a <main+49>:   leave 
0x0804841b <main+50>:   ret 
0x0804841c <main+51>:   nop 
0x0804841d <main+52>:   nop 
0x0804841e <main+53>:   nop 
0x0804841f <main+54>:   nop 
End of assembler dump. 
(gdb)

I'll explain now what happen with each line.

0x080483e9 <main+0>:    push   %ebp 
0x080483ea <main+1>:    mov    %esp,%ebp 
0x080483ec <main+3>:    sub    $0x8,%esp

It's a PROLOG.
First, EIP is saved from the function _init (or _start), that initialize this program, which called main().
Old frame pointer is saved(%ebp) and does, from current stack pointer(esp), the new frame pointer(mov %esp, %ebp).
After gcc-2.9.6 dummy bytes is always set free at functions, in this case 0x08 bytes.
It's the default process that any function does.