The most important in brief
Reading time 6 minutes
What is a buffer overflow?
A buffer overflow (also: buffer overflow) is a frequently encountered source of attack points in programs. The cause is incorrect handling of input and its length.
For example, a login data buffer may be designed to handle input of 12 bytes for the user name. If an input is 15 bytes long, 3 bytes more than expected, the programme may write the excess data beyond the buffer limit.
The overwritten memory areas should normally have contained processor instructions, specific data or addresses - which thus usually leads to a crash or at least undesired behaviour.
Buffer Overflow Attack
If the input stream is designed accordingly, however, arbitrary program code, also called shell code, can be injected via such a buffer overflow and often also brought to execution.
Since the attacker can work remotely on a network service, this is called a remote code execution vulnerability.
Security vulnerabilities in this category are among the most serious IT vulnerabilities and are regularly given the highest CVE score of 10.0.
Buffer overflow exploits
A buffer overflow exploit can be used to exploit an existing buffer overflow vulnerability. The goal of the exploit is to access the underlying operating system from the outside.
In doing so, the attacker goes far beyond the simple example shown above and directly changes the execution path in such a way that a shell code supplied with the buffer overflow is also directly executed.
This shell code contains any commands specified by the attacker. The creation of a remote shell on the attacked computer is frequently encountered.
Consequences of buffer overflows
The common consequences of a buffer overflow attack include system crashes and the risk of an attacker completely taking over the IT system.
Types of buffer overflow attacks.
There are several types of buffer overflow vulnerabilities. The three most common of these are:
- Stack-based buffer overflow attacks: This is the most common form of buffer overflow vulnerabilities. The stack-based approach involves an attacker sending data with malicious code to an application that stores the data in a stack buffer. This overwrites the data on the stack, including the return pointer, giving the attacker control over the transmissions.
- Heap-based buffer overflow attacks: A heap-based attack is more difficult to execute than the stack-based approach. In this attack, a program's memory area is flooded beyond the memory it uses for current runtime operations.
- Format string attacks A format string exploit occurs when an application processes input data as a command or does not effectively validate input data. This allows the attacker to execute code, read data in the stack, or cause segmentation errors in the application. This could trigger new actions that compromise the security and stability of the system.
Which programming languages are most vulnerable?
Almost all native applications, web servers and web application environments are vulnerable to buffer overflows. Environments written in interpreted or managed code languages such as C#, Java, Go, Rust and Python are immune to these types of attacks. However, by using native methods and system calls, exploitability cannot be completely ruled out here either.
Buffer overflow attacks are usually caused by programming errors during application development. These problems are particularly problematic in the programming language C/C++, as it does not inherently offer built-in protection against buffer overflows.
How can programmers prevent buffer overflows?
Buffer overflows are exploitable because of errors in the design or implementation of a piece of software. For software developers, the principle input is evil should always apply. In implementation as a programmer, it must follow that any input from the outside - be it via a web form, a network service, user input via the keyboard, or even simply by reading in an image file must be processed very conscientiously.
This includes correct handling of unexpectedly long strings, checking for permissible input patterns, filtering out prohibited characters (blacklisting) or accepting only permitted characters (whitelisting).
The buffer overflows shown in the examples resulted from unclean processing of an unexpectedly long string. A simple check for the maximum allowed length of the string of 15 characters would have been sufficient.
Protective mechanisms against buffer overflow attacks
Current operating systems and compilers provide protection mechanisms that make the successful exploitation of buffer overflow vulnerabilities much more difficult.
Address Space Layout Randomization (ASLR): Buffer overflow exploits usually need to know where the executable code is located. ASLR ensures that system libraries are loaded to a different address every time the system is started. This makes it much more difficult to use all system calls. Since Windows Vista, this protection mechanism is active by default.
- Stack Canaries or Stack Cookies: A stack cookie or stack canary makes it much more difficult to exploit stack-based buffer overflows by placing a random number on the stack between the return address and the local variables. Before the return is made to the calling function, this value is checked. If there is a change, for example due to a buffer overflow, the execution of the programme is stopped directly. This then leads to a crash of the software, but not to a system takeover. This protection mechanism must be activated in the compiler.
- Data Execution Prevention (DEP): This method prevents attackers from executing code in non-executable areas by marking memory areas as executable or non-executable. In particular, stack and heap areas are marked as non-executable (NX). Since Windows XP, this protection mechanism is activated by default.
- Overwrite protection for structured exception handling (SafeSEH & SEHOP): Attackers can attempt to overwrite the structured exception handling (SEH). These are function addresses that are jumped to in a detected error case. The additional storage of the correct addresses and a regular check prevent an attacker from overwriting them. This protective mechanism SEHOP takes effect on the operating system level and does not require a recompilation of the software, whereas SafeSEH does.
How effective are the protective mechanisms of the compilers and operating systems?
The automated protection mechanisms against buffer overflows can sometimes be circumvented. The programmer of the software is and remains responsible for ensuring that buffer overflows cannot occur in the first place.
Have we sparked your interest?
Just give us a call or write us a message!