The most important in brief

  • Buffers are memory areas in which data is stored.
  • A buffer overflow occurs when the amount of data exceeds the storage capacity of the buffer. As a result, the programme attempting to write the data to the buffer overwrites adjacent memory locations.
  • Possible consequences can range from crashes to a complete system takeover by an attacker.
Beitrag teilen

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.

Guide Buffer Overflow

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.

Example of a simple buffer overflow.

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.

  • System crashes: A buffer overflow attack usually causes the affected application to crash. It can also cause the IT system or a web server running on it to become unavailable or programmes to enter an infinite loop.
  • Attacker takes over IT system: In a buffer overflow attack, the attacker often brings his own shell code. The shell code is then executed on the vulnerable machine through the buffer overflow. This gives the attacker the same rights as the running programme with the buffer overflow vulnerability. Should the vulnerability be at the operating system level, the shell code will also be executed with administrative privileges.
  • Expansion of rights: If an attacker has taken over an IT system, there is a risk that further vulnerabilities present on the IT system or in the network environment can be exploited.

Types of buffer overflow attacks.

There are several types of buffer overflow vulnerabilities. The three most common of these are:

  1. 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.
  2. 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.
  3. 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.

  1. 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.
  2. 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.
  3. 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.

  • ASLR only provides protection for those libraries that have this functionality enabled. For some DLLs, this mechanism is disabled.
  • Sometimes stack cookies and stack canaries can also be bypassed if the attacker can trigger exception handling before checking the stack canary. If the SEH is overwritten at the same time, this can then lead to a successful exploit again.
  • Data Execution Prevention (DEP) can be bypassed by a concept called ROP (Return Oriented Programming).
  • Bypassing the override protection for exception handling is quite difficult, but possible under certain conditions.

Releated Content

Have we sparked your interest?

Just give us a call or write us a message!

Erfolgreich! We have received your request. Thank you very much.
Fehler! An error occurred while sending. Please use another way to contact us!

We use cookies to improve user experience and analyze website traffic. Read about how we use cookies and how you can control them by clicking "Privacy Preferences".

Privacy Preferences

When you visit any website, it may store or retrieve information through your browser, usually in the form of cookies. Since we respect your right to privacy, you can choose not to permit data collection from certain types of services. However, not allowing these services may impact your experience.