Saturday 23 December 2017

Exploiting Buffer Overflow - Part1: Introduction

Whether it is the stack clash vulnerability or buffer overflow, one has to hijack the control flow of the program and make it execute what the adversary wants to do. Data Execution Prevention (DEP) and Address Space Layout Randomisation (ASLR) makes exploiting buffer overflow harder but not impossible.

DEP prevents injecting code into overflown buffer in stack and executing them by changing the saved return address to jump to the injected code. DEP need support from hardware and allows codes execution only from marked region which are explicitly allowed. Only code segments will be allowed to execute.

Return Oriented Programming (ROP) uses simple sequence of instructions in the binary called gadgets that are discovered and used. Gadgets can be called from overflown buffer and linked together to perform what the adversary wanted. Key to this is discovering gadgets and the addresses where they are located. ASLR makes it harder by loading the Position Independent Executable (PIE) in random addresses.

In a long running applications like servers sometimes fork executable and makes copies to serve each request. Thus they tend to get loaded into the same start address making them easy to detect gadgets  and create exploits remotely.

gcc can use stack canary to detect if a buffer is overflown. This is a random value which is written at the end of the stack and verified when the call returns. If the canary is written to something other than what was expected, the program will terminate. However, if the program is such that it restarts like the long running application, it is not hard to learn the canary using brute force.

In a series of posts, I plan to document my experimentation with the buffer flow exploitation. Firstly the basics with an artificially created program. Then I will look into using fuzzers to look for security issues and then use them to create a workable exploits.




No comments:

Post a Comment