Buffer Overflow Attack #1

buffer overflow attack

My mom used to say “Too much of anything is harmful”. Well, this applies even to the buffer, which leads to Buffer Overflow Attack. In this blog, I will try to solve one of the challenge which was given to me by my professor AurĂ©lien Francillon during my masters from EURECOM, Sophia Antipolis, France. This challenge was part of the SysSec (System Security) Course.

According to Wiki:
In computer security and programming, a buffer overflow, or buffer overrun, is an anomaly where a program, while writing data to a buffer, overruns the buffer’s boundary and overwrites adjacent memory locations.
Buffers are areas of memory set aside to hold data, often while moving it from one section of a program to another, or between programs. Buffer overflows can often be triggered by malformed inputs; if one assumes all inputs will be smaller than a certain size and the buffer is created to be that size, if an anomalous transaction produces more data it could cause it to write past the end of the buffer. If this overwrites adjacent data or executable code, this may result in erratic program behavior, including memory access errors, incorrect results, and crashes.

The attack has been demonstrated and explained in the video

Buffer Overflow Attack

What is Buffer Overflow Attack?
As the wiki says, buffer overflow is an anomaly where a program, while writing data to a buffer, overruns the buffer’s boundary and overwrites adjacent memory locations.

Objective of the challenge:
Read the content of the file private

Exploiting Buffer Overflow:
Three main important steps:
1. Find the overflow point: In this case, we need 305 bytes to overflow. (Hit and Trial would work)
2. Using the shell code.
We will use the shell code:


This is of 45 bytes
3. Find the return address: We will try to find this but before that let’s try to understand few commands

Understanding commands and terms

GDB: GDB, the GNU Project debugger, allows to see what is going on `inside’ another program while it executes and/or what another program was doing at the moment it crashed.

Commands of gdb which we are going to use in this case:
disas: to disassemble a function
b *address: to put a breakpoint
x/120x $esp : to see the 120 values in stack pointer

Nop Sled: It is a sequence of nops (\x90)  instructions meant to “slide” the CPU’s instruction execution flow to its final,
desired destination whenever the program branches to a memory address anywhere on the slide. (As the wiki says)

The Idea:
Will keep the shell code in the buffer after nops, append the return address of the nops
Nop sled will take this to the shell code and shell will pop up

Using all of them to craft the exploit:

$(python -c 'print "\x90"*250+"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd\x80\xe8\xdc\xff\xff\xff/bin/sh"+"A"*10+"\x80\xe4\xff\xff"')

Too sum up the above command: 250 (nops) + 45 (shell) + 10 (A) + RET add (\x80\xe4\xff\xff)

I hope you enjoyed this write-up. Don’t forget to subscribe to my youtube channel and keep visiting my blog for new write-ups. Till then Au revoir

Leave a comment

Your email address will not be published. Required fields are marked *