$sp+460 starts the memory reading from the stack pointer ($sp) position offset by +460, which is around where our ebx register is located.īeforehand let’s slightly tweak our payload to make it more visible on the stack representation, instead of ‘A’ we will replace the 4 overflowed bytes with ‘B’ ( x42): 1.x/14x displays 14 bytes of memory in a hexadecimal format.Let’s decompose the command to understand how it works: We can also visualize what the stack looks like in memory from gdb with x/12x $sp-20. Now by checking the registers with the info registers commands we can verify that the ebx address is being overwritten: 1īy inputting a 504 character long string, we overwrite the whole ebx register: 1 Let’s now add a breakpoint in order to highlight how the EBX register got overwritten with an extra x41 (’A’): 1ĭump of assembler code for function main:Ġx0804918a : mov edx, DWORD PTR Ġx080491a9 : mov ebx, DWORD PTR īreakpoint 1 at 0x80491ac: file vuln. Nothing happens, it’s normal since EBX is not a critical register in our example program. We can use python to generate a string made of 501 occurrences of the letter ‘A’ ( 0x41 is hexadecimal for 65, which is the ASCII-code for the letter ‘A’).įrom gdb this can be done using the run command: ~]$ gdb. Well let’s now see in practice what happens when we input a 501 long string to our program. In our example, when we input a string longer than 500 characters, it will begin overwriting the register that’s lower on the stack (and higher up in the memory).įor example if we use a 501 characters long input, the following will happen: It’s important to note that, even though the stack itself grows upward from high-memory to lower-memory addresses, the buffer itself is filled from lower to higher memory addresses. In order to exploit the buffer overflow in our program, we are going to pass an input bigger than 500 characters to our buffer variable. In the previous article, the disassembly of our example program allowed us to understand what our program stack will looks like: Let’s now open our program with gdb: ~]$ gdb. z execstack: Disable NX (allowing stack segment to be executable). fno-stack-protector: Disable Stack Smashing protection. mpreferred-stack-boundary=2: Ensure that the stack is set up into 4-bytes increments, preventing optimisation of the stack segmentation that could make our example confusing.

g: Generates debug information to be used by GDB debugger. ~]$ sudo echo 0 > /proc/sys/kernel/randomize_va_space # disable ~]$ gcc -m32 -g -mpreferred-stack-boundary=2 -fno-stack-protector -z execstack vuln.c -o vuln

No possible Stack or Heap execution, these memory spaces are intended to only contain variables and pointers but never executable code.įor the learning purpose of our example, we are going to disable these protections and force a 32 bits compilation.

The integrity of the secrets are checked and the program immediately interrupt if modification is detected. These secret values (”Canaries”) are inserted between data segments in the stack.

SSP protection ( Stack- Smashing Protector) detects stack buffer overrun by aborting if a secret value on the stack is changed.

At each new execution, the stored data is placed in different memory spaces.

ASLR protection ( Address Space Layout Randomization) randomly arranges the address space positions of key data areas of a program.

Some of the common and highly effective security measures include for example: These measures have made exploiting vulnerabilities such as buffer overflow quite challenging. Setting up our environmentĪs previously stated in the introduction, today’s memory layout of a running application has become significantly more complex due to the implementation of various security measures. In this article we will details how to exploit a buffer overflow in order to achieve remote code execution via shellcode injection. By this third article of the Buffer Overflow series we should be familiar with:

Buffer overflow minecraft