Buffer Overflow

Program Memory

• When a program runs, it is loaded into memory.

• A running program is called a process.

• Text segment (also known as code segment): stores the executable code of the program (usually read-only).
• Data segment: stores static/global variables initialized in the program.
• BSS (block started by symbol) segment: stores uninitialized static/global variables. These variables will be initialized with zeros.
• Heap: provides space for dynamic memory allocation (caused by malloc, calloc, realloc, free, etc).

• Stack: is simple data structure with a LIFO (last-in-first-out access policy). Stack stores local variables defined inside functions, and data related to function calls (return address, arguments, etc)

• Sizes of text, data, and BSS segment are known as soon as compilation or assembly is completed.
• Stack and heap segments will grow and shrink during program execution.
• Therefore, they tend to be configured such that they grow toward each other.
• The boundary between them is flexible.
• Both can grow until all available memory is used.

• Create a file called mem_layout.c

• Run the following commands

1
2
3
4
5
 
sudo apt-get update
sudo apt-get install -y gcc-multilib g++-multilib
gcc -m32 -W -c mem_layout.c
gcc -m32 -o mem_layout mem_layout.o
size mem_layout mem_layout.o
 

• Why don’t we see the stack and heap information?

• Create a file called mem_layout_print.c

  • You can make a copy from mem_layout.c and edit.

• Run the following commands

1
2
 
gcc -m32 -o mem_layout_print mem_layout_print.o
./mem_layout_print
 

• Can you relate the variables’ position in memory to their respective position in a program’s memory layout?

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
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
 
## Stack Memory


- When a function is called, a block of memory called stack frame will 
be pushed onto the top of stack. 
- A stack frame contains four regions:
  - Arguments that are passed to the function (if they don't fit on the 
  general purpose registers)
  - Return address (the address of the instructions right after 
  the function call
  - Previous frame pointer
  - Local variables of the function
- When the program first starts, the stack contains only one frame, 
that of the main function.





<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/buffer-overflow/stack_mem_layout-480.webp 480w,/assets/img/courses/csc302/buffer-overflow/stack_mem_layout-800.webp 800w,/assets/img/courses/csc302/buffer-overflow/stack_mem_layout-1400.webp 1400w,"
            type="image/webp"
          
          
            sizes="95vw"
          
        >
      
    
    <img
      src="/assets/img/courses/csc302/buffer-overflow/stack_mem_layout.png"
      
      
        width="50%"
      
      
        height="auto"
      
      
      
        alt="Stack memory layout"
      
      
      
        data-zoomable
      
      
        loading="lazy"
      
      onerror="this.onerror=null; $('.responsive-img-srcset').remove();"
    >
  </picture>

  
</figure>




- We can call a function from inside a function. 
- Any time we enter a function, a stack from is allocated on top of the stack. 
  - When the function returns, the allocated space is released. 





<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/buffer-overflow/call_chain-480.webp 480w,/assets/img/courses/csc302/buffer-overflow/call_chain-800.webp 800w,/assets/img/courses/csc302/buffer-overflow/call_chain-1400.webp 1400w,"
            type="image/webp"
          
          
            sizes="95vw"
          
        >
      
    
    <img
      src="/assets/img/courses/csc302/buffer-overflow/call_chain.png"
      
      
        width="50%"
      
      
        height="auto"
      
      
      
        alt="Chain of function calls"
      
      
      
        data-zoomable
      
      
        loading="lazy"
      
      onerror="this.onerror=null; $('.responsive-img-srcset').remove();"
    >
  </picture>

  
</figure>


 

Buffer overflow attack

• Memory copy happens in programming when data from one place (source) is duplicated to another place (destination).
• Before copying can happen, memory needs to be allocated at the destination.
• If the allocation fails to be sufficient, it will result in an overflow.

• One of the oldest and most well-known attacks.

• Can still be found buried in legacy or glue code from third party libraries as web sites get more complex and evolved.
• An important point of learning as you work through the theory and practice of this exploit:
  • C programming
  • C Assembler
  • Linux debugger using gdb
  • Engage in mathematics to understand the breaking points and the hex contents in memory in order to place an attack
• Create strcpy_overflow.c

• Run the following commands

1
2
 
gcc -m32 -o strcpy_overflow strcpy_overflow.c
./strcpy_overflow
 

• What happens?
• The region above the buffer includes critical values, including the return address and the previous frame pointer.
• The consequences of a modified return address (due to buffer overflow) include:
  • The new address (virtual address) might not be mapped to any physical address, leading to an invalid return instruction and a crashed program.
  • The address might be mapped to a physical address in protected system space, leading to a failed jump and a crashed program.
  • The address might be mapped to a physical address that does not contain any valid instruction, leading to a failed return and a crashed program.
  • The address might be mapped to a physical address that happens to contain valid machine instructions, leading to a continuing program with logic different from the original program.
• Run the following commands

1
2
3
4
 
git clone https://github.com/longld/peda.git
echo "source $HOME/peda/peda.py" > $HOME/.gdbinit
gcc -m32 -g -o gdb_strcpy_overflow strcpy_overflow.c
gdb gdb_strcpy_overflow
 

• Setup gdb with a breakpoint at main (b main) and start running (run).
• A new GDB command is si: executing the next instruction (machine or code instruction).
  • It will execute the highlighted (greened and arrowed) instruction in the code section.
  • If the Assembly instruction is calling another function, we need to use ni if we don’t want to step into that instruction.
• Create stack.c

• This file has a clear buffer overflow issue.
  • How can we exploit this?

• Rerun mem_layout_print several times

1
2
3
 
./mem_layout_print
./mem_layout_print
./mem_layout_print
 

• You will notice the addresses printed out change each time. This is one of the system protection against buffer overflow attacks.
• First, we need to disable the countermeasures

1
 
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
 

• Rerun mem_layout_print several time to confirm that addresses are not changing

1
2
3
 
./mem_layout_print
./mem_layout_print
./mem_layout_print
 

• We need to include the following flags in compiling
  • -z execstack
  • -fno-stack-protector

1
2
3
4
5
6
7
 
gcc -m32 -o stack -z execstack -fno-stack-protector stack.c
sudo chown root stack
sudo chmod 4755 stack
echo "aaaa" > badfile
./stack
echo "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" > badfile
./stack
 

• Why segmentation fault?

• How do we know (guess) where the stack frame of foo() will be for us to find out where the malicious code is located (and hence set the relevant jump address)?
  • Fixed starting address of the stack (before countermeasure).
  • The stack is shallow (good programming practice don’t use deeply nested functions).
• To make a (much more) educated guess

1
2
3
4
 
gcc -m32 -g -o gdb_stack -z execstack -fno-stack-protector stack.c
rm badfile
touch badfile
gdb gdb_stack
 

• Run the following GDB command inside gdb (gdb-peda)

1
2
3
4
5
6
 
break foo
run
print $ebp
print &buffer
print <hex address of ebp> - <hex address of buffer>
quit
 

• Take notes of your $ebp
• What is the result of the subtraction?
  • Either 108 (decimal) or 0x6C (hex)?

• Payload: A shellcode containing the /bin/sh command
• Use Assembly’s NOP to improve the attack chance

• Create and run exploit.c

• Does it work
  • Unlikely to work the first time.
  • If hang, Ctrl-C to quit out of the hanging stack program.
  • Need to modify added hex value (increment multiples of 4 at a time)

• Safer functions: specification of maximum data length to be copied
• Safer dynamic link library: dynamic link to safer libraries (as opposed to calling unsafe functions)
• Program static analyzer: warn of code patterns that could lead to buffer overflow
• Programming language: self-check against buffer overflow in the language
• Compiler: -fno-stack-protector
• Operating system: kernel.randomize_va_space

```