Buffer overflows
Introduction
Welcome to module 3 of this workshop. So far we have discussed the Linux operating system and debugging on Linux platform. In this module, we will be talking about Buffer overflows in more granular detail and we will try to focus buffer overflows as generic as we can in order to keep this concept independent from any specific platform. This would be more of a knowledge-based module, which will hopefully build baseline knowledge about buffer overflows, its types, precautionary measures, and the reasons for buffer overflows.
We will be also discussing types of overflows and how you can exploit them and get the illegitimate access to the operating system.
Prerequisites
• Knowledge of TCP/IP protocols
• Basic knowledge of operating systems
• Complete the previous two modules of this workshop
• Should have at least beginner level concepts in programming
The Basics
A stack is a contiguous block of memory which is used by functions. Two instructions are used to put or remove data from the stack, “PUSH” puts data on the stack, and “POP” removes data from the stack.
The stack works on a last in first out “LIFO” basis and grows downwards towards lower memory addresses on Intel based systems.
The ESP stack pointer points to the top of the stack. The stack is heavily used by functions in order to hold function arguments and dynamically allocate space for local variables.
Why do we need stack?
Generally, what happens is when any function is called by any program written in any programming language, the function arguments are pushed backwards on the stack, now the instruction pointer (EIP) is pushed afterwards and this is called the return address of the function. The return address when a “call” instruction is called it pushes its address on the stack to return to it when the function is done.
In today’s research, stack based buffer overflows are one of the most common vulnerabilities in the programs.
What is Buffer Overflow?
Buffer overflow is basically an overflow that occurs when a function copies data into a buffer without doing any prior bounding or boundary checks. This means if the source data is large than the destination data in size then the buffer will overflow toward a higher memory address and probably overwrite the previous data on the stack.
Types of Buffer Overflows
In the field of security testing and the surrounding industry describes buffer overflows in different ways based on the different reasons and the nature of exploitations. We have researched and classified the buffer overflows in five different types and tried to cover many of them, as follows:
Stack Buffer Overflow
The stack is where the computer declares and initializes the variables used in a software program. In a stack based buffer overflow, basically more data is written to the stack than it can legitimately allocate, causing the stack to be overwritten, including the “return pointer” that tells the system where to go once it finishes processing the stack. Now what really happens is that hackers can therefore use a stack overflow to rewrite the return pointer and direct the system to malicious code.
Heap Buffer Overflow
A heap buffer overflow occurs when too much data is written to the portion of memory allocated to the software program for storing the program data while it is running.
Heap based buffer overflows often lead to a system crash and this is mostly due to data corruption, with the reason that the program is overwritten while it is running, or to the execution of malicious code which is written into the heap buffer during the overflow and has thereby bypassed the system’s standard security
Off-by-One Errors (loop of code)
An off-by-one error is a specific type of buffer overflow that occurs when a value is one iteration off what it is expected to be. This can often be due to miscounting the number of times a program should call a specific loop of code. The error may result in the rewriting of one digit in the return pointer in the stack, which therefore allows a hacker to direct the pointer to an address containing malicious code.
Buffer Overrun
A buffer overrun occurs when too much data is sent to the small block of buffer memory used by CD and DVD burners. These buffers exist to provide a steady flow of information from the computer to the device. Data is read from the buffer at a specific speed and must be fed into the buffer at the same speed, otherwise data is overwritten before it is used. This results in file corruption and unsuccessful burning .
Format String Attack
A format string attack occurs when a program reads input from the user, or other software, and processes the input as a string of one or more commands. If the command that is received differs from that which is expected, such as being longer or shorter than the allocated data space, the program may crash, quit or make up for the missing information by reading extra data from the stack; allowing the execution of malicious code.
How to Mitigate Buffer Overflows?
A Blackhat team presentation stated two different approaches. The first is to make software safe, by verifying code and ensuring that there cannot be any buffer overflows. The other approach tries to reduce the likelihood of exploitation.
Generally, in the field of secure coding practice within the field of software development, there are three techniques, which are widely deployed.
Non-executable stack, heap, data sections
As classic buffer overflows rely on the injection of arbitrary code and executing it, preventing applications from executing code on writeable pages stops this form of operation. Several techniques, such as the return-into-libc measure, allow still for arbitrary code execution.
Address Space Layout Randomization (ASLR)
Classic buffer overflows and methods working around non-executable stacks heavily rely on known fixed addresses, which ASLR addresses by randomizing the addresses of certain pages in the process’ address space. A collection of techniques working around this problem has been developed.
Stack Smashing Protection (SSP)
Since the heart of most buffer overflows lies in overwriting a return address on the stack to redirect the execution flow, several sorts of protection and detection measures have been developed
Why you should learn about buffer overflows?
Well, this topic of buffer overflows basically comes from software coding practices and generally computer programmers who perform quality assurance tasks in the software development lifecycle are very much aware of program overflows. But these days security professionals, or ethical hackers,are required to have both theoretical as well practical knowledge and experience on detecting buffer overflows and also expertise in exploitation and coding exploits against these buffer overflows. Hackers also use more or less similar technologies and techniques to detect buffer overflows the way normal software developers do, however, there is a big difference in the intent.
We will list some tools that are utilized in buffer overflows detection or exploitation lifecycles.
• Immunity Debugger
• GNU & GDB
• Disassemblers
• IDA Pro
• OllyDbg
• Stack Shield
• BOU (Buffer Overflow Utility)
• BOON
• BLAST
• Eclipse
• LDRA Testbed
• GNU & GDB
• Disassemblers
• IDA Pro
• OllyDbg
• Stack Shield
• BOU (Buffer Overflow Utility)
• BOON
• BLAST
• Eclipse
• LDRA Testbed
There are many tools that can help in detecting buffer overflows, finding buffer overflows are a broader topic.
Methods for Buffer overflows testing
There are generally two known methods for testing for buffer overflows in any application, and this depends on access to the code of application.
Black Box Testing
This is the type of testing to use when you don’t have access to the source of the program or application and you have to identify buffer overflows. This is the case normally and mostly happens with security professionals where they have to find out buffer overflows and they don’t have access to source code. Fuzzing is the technique that is mostly utilized in order to detect the buffer overflow in such scenarios.
Gray Box Testing
This is the type where you have direct access to the source code of the application and you want to detect buffer overflows. This is usually the case with software quality assurance people who have access to the source code and are equipped with tools to perform automatic testing and detect error.
Summary
In this module we have covered many aspects of buffer overflows ranging from defining and presenting types, methods and techniques to detect and prevent the buffer overflows at the same time. In upcoming modules, we will be performing actual testing and looking into vulnerable code in a programming language.