Identify, mitigate & prevent buffer overflow attacks on your systems

March 21, 2023 - TuxCare PR Team

Buffer overflow vulnerabilities are still a common route by which cyber criminals get illegal access to computer systems. It’s a growing problem too as there is a steady year-on-year increase in buffer overflow vulnerabilities.

It’s an old problem too. You might not know this, but buffer overflow attacks are one of the oldest attack vectors – buffer overflows were first identified as a security breach risk in 1972.

With tens of thousands of known buffer overflow vulnerabilities out there, including profound cases such as Heartbleed, developers and sysadmins must have a good grip on how to detect, mitigate and also prevent buffer overflow attacks.

Read on to see what a buffer overflow attack is, and what your organization can do to stop these threats.

What is a buffer overflow attack?

First, you need to understand what a buffer is in terms of computer software. Buffers are holding areas for data: temporary storage areas where data is kept while a program is running. Buffers are required because interconnected systems, including applications, are not always in sync.

In other words, sometimes when information is sent from one point to another, the recipient isn’t ready – and the information must wait somewhere. That’s what a buffer is used for: buffers support coordination. This could be because the two points operate at different speeds, or with different priorities.

Understanding a buffer overflow

Computer memory is finite, so programmers must define storage spaces to a finite size – including the size of a buffer. For example, a programmer will define a buffer to store an 8-character password as 8 bytes. When the password is written and sent to the buffer, the presumption would be that the password is no longer than 8 characters in length – and therefore fits in the buffer.

A buffer overflow occurs when, instead of an 8-character password, a 10-character password is sent to the buffer. When that happens, the computer program is forced to keep the data somewhere – and, as a result, the excess data is stored in another buffer. In some cases, the additional two characters can end up stored somewhere that it overwrites important data or even program code.

Of course, programmers should prevent this from happening by designing their code to check for inputs that exceed buffer lengths – or by using a range of other mitigating tools. However, if the programmer simply relies on an assumption that the input will always match the buffer size, then a buffer overflow vulnerability can emerge – and that could lead to a buffer overflow attack.

How a buffer overflow attack works

In simple terms, in a buffer overflow attack, a hacker intentionally writes data that exceeds the buffer size into a buffer – triggering a buffer overflow. The intent may be to crash the application or to write malicious data (including executable code) into a desired data storage space.

For example, if an attacker coordinates the buffer overflow correctly, the attacker can write malicious code into a targeted space that holds executable code – and then execute their own code. Similarly, the hacker can use a buffer overflow to overwrite buffer data to change the behavior of a program.

There are essentially two types of buffer overflow attacks:

Stack buffer overflow attacks are the most common type of buffer overflow attack and involve overwriting stack memory that is used during the execution of a program. By writing excess data to the buffer, the hacker almost always succeeds in corrupting the data in the buffer next to it.
Heap overflows involve an attack where the hacker tries to flood the memory space that is allocated to a program beyond what’s used for currently running operations. It corrupts the data in ways that mean that the application that is running overwrites its internal structures.

Both of these attack strategies can lead to compromised systems, data loss, and service disruption.

What are the risks of a buffer overflow attack?

Buffer overflows are just one of many attack vectors out there, and the intentions overlap with many other vulnerability exploits.

It’s worth noting that, even where remote code execution is too challenging with a buffer overflow attack, hackers can nonetheless cause havoc by using buffer overflows to simply cause application crashes – and a Denial of Service (DoS) condition – which, in turn, will lead to other consequences.

Furthermore, it can be argued that a buffer overflow attack is often just the first step in a much more complex attack plan – whether the end goal is remote code execution, privilege escalation, or something else.

Of course, buffer overflow attacks have unique characteristics, but we can generally suggest that hackers would use a buffer overflow attack to achieve any one of the following goals:

Service disruption: Using a buffer overflow attack, a hacker could engineer a service disruption. It can be relatively easy to use a buffer overflow vulnerability to cause an application to crash, bringing down the services it supports.
Unauthorized access: A malevolent actor can use a buffer overflow vulnerability to gain illicit access to computing infrastructure – which could open the door to an endless array of compromises.
Code execution: Through a buffer overflow attack, an attacker can use your systems to execute code that the attacker wrote for criminal gain.
Data loss: Buffer overflow attacks can be used to siphon off data by manipulating application behavior then redirect outputs and illegally capture data flows.

In the broad, the risks of buffer overflow vulnerabilities are similar to most vulnerabilities, and are most certainly just as serious.

Real-life examples of buffer overflow vulnerabilities

At the start of this article, we pointed to the fact that buffer overflow vulnerabilities were first identified in 1972. While some cases of successful attacks would have emerged soon after, the computing world of 50-odd years ago was not as pervasive, or as exposed, as it is today.

The first key example of a widespread buffer overflow attack is the Morris worm. In 1988, this worm traveled across the nascent internet to bring down 10% of the then “internet” in just two days. Across two years, this computer worm affected 60,000 computers.

Perhaps the most widely known buffer overflow vulnerability is Heartbleed. It surfaced in 2014 as a critical vulnerability in a piece of software that is widely used: OpenSSL. Countless internet servers run by prominent companies, such as Yahoo, used the OpenSSL cryptography library to implement TLS (the transport layer security) protocol.

This buffer overflow vulnerability was caused by a simple error too. It came down to a classic lack of bounds checking in the computer code behind OpenSSL. Of course, OpenSSL was eventually fixed via a patch but not until the vulnerability caused widespread alarm – and damage.

The risks are not limited to the technical corners of the internet. Popular applications are also at risk of buffer overflow exploits: popular chat app WhatsApp suffers from a buffer overflow vulnerability, which was filed as CVE-2019-3568 in May 2019. In this case, attackers were able to use the vulnerability to execute malicious code on a user’s mobile device by manipulating packets right at the start of a voice call.

Some other examples include:

The Stuxnet worm in 2010: Targeting the Iranian nuclear program, the attack exploited a buffer overflow vulnerability in the Windows operating system.
The Sony Pictures hack in 2014: Attackers used a buffer overflow exploit in the company’s network to gain access to sensitive information and cause widespread disruption.
The WannaCry ransomware attack in May 2017: This attack affected more than 200,000 computers in 150 countries by exploiting a buffer overflow vulnerability in Microsoft Windows.
The SolarWinds Supply Chain Attack in December 2020: Attackers used a buffer overflow exploit in the SolarWinds Orion network management software, gaining access to the networks of multiple organizations.
The Zscaler Zero-Day Exploit in November 2021: This attack impacted Zscaler’s cloud-based security services by using a buffer overflow vulnerability to execute arbitrary code.

Mitigating and preventing buffer overflow attacks

The buffer overflow landscape has changed a bit over time: in some ways, the most elementary buffer overflow risks are now automatically mitigated. OS and software vendors as well as programmers tend to implement practices that limit buffer overflows even when there is an underlying vulnerability.

Both software vendors and the users of their software need to stay aware of buffer overflow risks – and mitigate accordingly. That said, users can only do so much to secure their environments against buffer overflow attacks. It is down to the vendor to program software safely and to patch rapidly when needed.

Prevention on the vendor side

Software vendors are ultimately responsible for preventing buffer overflow vulnerabilities. The existence of opportunities to exploit buffer constraints often comes down to the characteristics of the software.

It can be as simple as staying aware of the limitations of the programming language used, and the implied risks of that language: C and C++ have no built-in protection against buffer overflows, whereas Java, PERL, and C# have some safety mechanisms in place.

Here are a few specific approaches that vendors can take:

Watch out for assumptions: Programmers can often assume certain facts around the operations of an application, but attackers can exploit these assumptions. Instead, programmers should code with the view that assumptions can be violated. Bounds checking, which involves verifying that an input does not exceed the buffer size, is a key example.
Address Space Layout Randomization (ASLR): Many buffer overflow attacks rely on the knowledge of the location of address space. By randomizing the layout of address space, a buffer overflow is more difficult to coordinate, as the target location continuously and randomly shifts.
Limit execution: Configuring stacks as non-executable means that attackers cannot use buffer overflows to execute malicious code in a stack.
Avoid programming errors: Buffer overflow opportunities are, more often than not, down to specific computer code. Programmers must behave conscientiously and avoid making errors that can be exploited by attackers.

The above points can mitigate the risks of buffer overflow attacks, but ultimately, mistakes will inevitably be made.

Mitigation from the user side

In discussing the options that vendors can harness to fortify their software against buffer overflow attacks, we left one key point out: buffer overflow vulnerabilities are often only discovered once software is already released into the wild.

This scenario is not unusual and mirrors what typically happens with the discovery of vulnerabilities. There is a simple fix: the vendor releases a patch that closes the buffer overflow vulnerability, and the end-user installs the patch to mitigate the vulnerability.

Where end-users are motivated to secure their workloads against buffer overflow vulnerabilities, the most effective option by a long distance will always be regular, consistent application of patches. However, effective patching is easier said than done, as patching can be disruptive and resource intensive.

Automated, rebootless patching through tools such as KernelCare helps – by reducing resource requirements and by eliminating the need for server disruptions. Nonetheless, sometimes buffer overflow vulnerabilities are unknown, or there is simply no effective patch. Some options that users can make use of include:

Monitor for unusual behavior: Closely watch your server and network performance and logs to catch intruder activity just as you would watch out for any other exploit.
Manage privileges: Attackers often rely on loosely managed permissions and privileges. Ensure that your applications and your users operate with the minimum of access permissions to ensure that attackers do not have the opportunity to escalate.
Threat prevention tools: Zero-day vulnerabilities can be rapidly exploited, but automated tools, such as web application firewalls, can stop some attacks by monitoring for suspicious behavior patterns and simply stopping the traffic from suspicious sources.

Finally, we would suggest that end-users can protect their workloads by carefully choosing their OS and software vendors. Ask key questions: what is the reputation of the vendor when it comes to software security? Does the vendor rapidly release patches when a vulnerability is identified?

Because buffer overflow vulnerabilities are essentially a programming issue, it comes down to the vendors to manage the vulnerability and – as the end-user – you can protect yourself by carefully vetting which vendors you work with.

The wrap-up

Software vendors are ultimately responsible for mitigating buffer overflow vulnerabilities. It comes down to the application code, after all. Thankfully, vendors usually respond by releasing patches that remove the opportunities to exploit buffer overflows.

For organizations, rapid introduction of new patches is critical. Automated tools such as KernelCare Enterprise help by removing the friction in patching. Nonetheless, as with any other cyber threat, companies should also implement wider cyber hygiene measures to limit the risks of buffer overflow vulnerabilities – and vulnerabilities across the board.

Summary