Buffer overflow vulnerabilities remain a common way in which cyber criminals gain illegal entry into computer systems. According to the National Vulnerability Database, there has been a steady increase in reported buffer overflow vulnerabilities over the decades – with 842 reported just last year.In fact, 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 18,355 known buffer overflow vulnerabilities out there, including profound cases such as Heartbleed, developers and sysadmins must get 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?
- Understanding a buffer overflow
- How a buffer overflow attack works
- What are the risks of a buffer overflow attack?
- Real-life examples of buffer overflow vulnerabilities
- Mitigating and preventing buffer overflow attacks
- Prevention on the vendor side
- Mitigation from the user side
- The wrap-up
What is a buffer overflow attack?
First, let’s consider 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 co-ordination. 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 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. Computer programs are forced to keep the data somewhere – and as a result, the excess data is stored in another buffer. The additional two characters may well overwrite important data or even code somewhere else.
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 may emerge – which 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, with specific intent. This 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 co-ordinates the buffer overflow correctly the attacker can write malicious code into a targeted space that holds executable code – and then execute their code with malintent. Or, 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 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 – and the intentions overlap with many other vulnerabilities.
It’s worth noting that, even if 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 or privilege escalation.
Of course, buffer overflow attacks have unique characteristics, and in the main, we can 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 is relatively easy to use a buffer overflow vulnerability to cause application to crash, bringing down your services.
- Unauthorized access. A malevolent actor can use a buffer overflow vulnerability to gain illicit access to your 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 through buffer overflows attackers can redirect outputs and illegally capture data flows.
In the broad, the risks of buffer overflow vulnerabilities are similar to most vulnerabilities, and most certainly equally 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 affecting 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: 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, formally 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.
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. In the main 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 is 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 or 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 co-ordinate 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 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. And 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 our 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 suspect sources.
Finally, we would suggest that end users can protect their workloads by carefully choosing their 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 is down to the vendors to manage – and as the end user, you can protect yourself by carefully vetting your vendors.
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 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 in the broad.