Check the status of CVEs. Learn More.
Keeping your systems up 100% of the time requires live patching. Our solutions will align strongly with your risk, compliance, and operational uptime requirements.
TuxCare is trusted by the most innovative companies across the globe.
Learn about TuxCare's modern approach to reducing cybersecurity risk with Blogs, White Papers, and more.
Continually increasing Cybersecurity, stability, and availability of Linux servers and open source software since 2009.
TuxCare provides live security patching for numerous industries. Learn how TuxCare is minimizing risk for companies around the world.
2x a month. No spam.
February 17, 2021 - TuxCare expert team
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.
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.
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.
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:
Both attack strategies can lead to compromised systems, data loss – and service disruption.
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:
In the broad, the risks of buffer overflow vulnerabilities are similar to most vulnerabilities, and most certainly equally serious.
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:
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:
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.
Learn About Live Patching with TuxCare
End-of-life software is just a fact of our fast-paced technology...
Look, everyone knows that it’s a tough act. Thousands of...
The public sector, including state and federal agencies, are at...
If your organization deploys IoT solutions, you know that development...
We continue to look at the code issues that cause...
Catastrophic risks such as natural disasters and indeed cyberattacks require...