Buffer overflow vulnerabilities are a serious threat to computer security, and they have been responsible for some of the most high-profile security incidents in recent years. The Phone Buffer Service vulnerability is just one example of a buffer overflow vulnerability, and there have been many others that have affected everything from web servers to critical infrastructure.
This guide will delve deep into buffer overflows, how much damage they can cause, and how businesses and institutions can protect their infrastructure against them.
Overwriting memory
Data transfer is more organized than one might believe. While it ensures the seamless transfer of information, it isn’t accomplished by shoving every bit and byte onto the receiver in a lump sum. A device or program can only process so much data at a given time.
To prevent the receiving end from being overwhelmed, developers create a temporary storage system in the device or program to hold data and release it upon request. Generally, these data buffers utilize a first-in, first-out (FIFO) mechanic; exactly as it says, the first bit of data to arrive in the buffer is also the first to leave.
Users aren’t usually aware of this process because it happens quickly, and the system facilitates multiple tasks simultaneously. However, the core functions of a data buffer are twofold: writing data into the buffer and ensuring it’s properly structured. These functions occur at different rates to mitigate the risk of data transfer issues.
Unfortunately, data stored in buffers is prone to an attack cybersecurity professionals call buffer overflow. According to the Open Worldwide Application Security Project (OWASP), a nonprofit advocating open-source software, buffer overflow works by intentionally stuffing more data than the buffer’s capacity. It overwrites the prevailing data in the buffer with the attackers’ own.
As a result, when the device or program requests data, it ends up with malicious data placed by the attack. The attackers would then gain control of the device or program to perform as much mischief as they desire—and this is just one of several ways of executing it.
- Stack buffer overrun
Also known as stack-based buffer overflow, this approach targets stack buffers, which work using a last-in, first-out (LIFO) mechanic. Under normal conditions, the stack remains empty until the device or program requests user input—for example, a username and password. The stack gets filled with information, including the user input, and is later released to a specified address.
This attack exploits the stack buffer’s finite space, triggering an overflow by feeding user input it can’t store without overwriting the prevailing data. As mentioned earlier, the input can be malicious, which can wrest control of a device or program.
- Heap smashing
Also called heap-based buffer overflow, this attack targets the heap section of a data buffer. The heap contains device or program data, which assigns space during runtime via dynamic memory allocation. The attack floods the space designated for such data with malicious data, affecting a device or program’s functionality.
One high-profile example is the zero-day vulnerability discovered in version 8 of Google Chrome two years ago. While authorities and experts recorded no incidents that exploited this vulnerability (heap smashing is rare due to its difficulty), it was only found after years of being “in the wild,” which is worrisome.
- Integer overflow
An integer overflow is best described as surpassing the limit of a car’s odometer; if the miles traveled exceed the number of digits on the odometer, the total resets to zero. The overflow entails messing with the buffer’s arithmetic operation, so the result can’t fit into the buffer. The resulting errors can leave the device or program open to further exploits.
Vulnerability of the decade
Buffer overflows may not get as much media attention as data breaches, but saying they aren’t dangerous is dangerous. There’s a reason that researchers at the Oregon Graduate Institute of Science and Technology dubbed buffer overflows the “vulnerability of the decade” from 1988 to 1998. Sadly, that remains the case in the current decade.
A whitepaper jointly published by researchers from Pakistan and Saudi Arabia last year cited the prevalence of buffer overflow attacks from the MITRE Corporation’s Common Vulnerabilities and Exposures (CVE) program. Amid highs and lows, buffer overflow attacks have been on an upward trend since 1999, reaching a peak in 2018 with over 1,500 cases reported.
One of the most well-known buffer overflow vulnerabilities is the Phone Buffer Service vulnerability, which was discovered in 2000. This vulnerability affected the Phone Book Service, an optional component shipped with Microsoft Windows NT 4.0 and Windows 2000 servers. The Phone Book Service was used in conjunction with dial-up networking clients to provide computers with a pre-populated list of dial-up networking servers.
The vulnerability was caused by an unchecked buffer in the Phone Book Service that a particular type of malformed URL could exploit. A malicious user could execute arbitrary code on an IIS 4 or IIS 5 web server running the Phone Book Service, potentially enabling them to gain privileges on the machine. This could allow the attacker to add, change or delete specific data, run code already on the server, or upload new code to the server and run it.
The vulnerability was discovered by two security research firms, CORE-SDI and Microsoft, the latter after receiving a report from Stake, an online casino platform. Microsoft released a patch to address the vulnerability, but the incident highlighted the potential dangers of buffer overflow vulnerabilities and the importance of software security.
The CVE program has recorded roughly 14,000 cases since 1999, but buffer overflow attacks have occurred much earlier. In fact, the infamous Morris Worm of 1989, one of the first major cyberattacks in the U.S., was the first significant use of buffer overflows.
Named after its creator, Robert Tappan Morris, the Morris Worm was a self-replicating program that targeted Unix operating systems, particularly their Finger networks. While it didn’t destroy any files or the operating system, it denied civilian and military users access to their networks for days, if not weeks. It was essentially a denial-of-service attack.
Morris said he only intended for the worm to demonstrate the weaknesses of the infrastructure at the time, never for criminal activity. However, the speed at which the worm replicated caused an estimated 10% of Unix computers to be rendered inoperable within 24 hours. A Federal Bureau of Investigation report estimated economic losses between USD$100,000 and millions.
In spite of his intentions, Morris became the first individual to be indicted for violation of the Computer Fraud and Abuse Act of 1986 (though he rendered community service instead of jail time). Nevertheless, experts believe a Morris Worm-like attack today is unlikely due to shifting security priorities and technological advances.
That said, the evolution of buffer overflow attacks soldiered on for the same reasons, affecting systems that enhance internet security. In 2014, Google and then-Codenomicon (now part of the Synopsys Group) discovered a security bug during an update of their security testing products. It would later be given a terrifying yet apt name: Heartbleed.
Heartbleed targets the “heartbeat,” a mechanism allowing devices to maintain communication even without user activity. The heartbeat is a core feature of the Secure Socket Layer (SSL) protocol and its successor, Transfer Layer Security (TLS) protocol.
Tests conducted by Codenomicon at the time revealed that Heartbleed leaks encryption keys to attackers, allowing them to infiltrate the servers and leave without a trace. It was discovered in earlier versions of OpenSSL, which couldn’t verify the credibility of the heartbeat request.
For context, heartbeats are usually 40 KB in size, so the device’s respective buffers must allocate that much space to receive them. Heartbleed enables faking one—say, sending out a 40-KB beat but is, in actuality, half of that. The receiving end only gets 20 KB and would later send it back with the other 20 KB, possibly containing sensitive information such as passwords.
The discovery led to widely-used programs like Mozilla Firefox and Google Chrome to drop OpenSSL (the latter creating its own, called BoringSSL). While OpenSSL rolled out a critical patch to address it last November, its open-source nature brings the unlikelihood of replicating the Heartbleed vulnerability into question. In other words, this bug is still “in the wild.”
Protective measures
Like any other cyber threat, letting the inevitable march of time deal with buffer overflow issues is terrible advice. New technology solves as many solutions as it creates new problems, and computer security is no exception. Otherwise, this interconnected age would see no need for protective measures beyond not letting anyone use your computer without permission.
In most situations, buffer overflow attacks transpire due to code oversight and poor decision-making. OWASP points out that the C or C++ language is highly prone to such attacks. But as this language is a globally-recognized programming standard, urging people to stop using C or C++ might do more harm than good.
If employing C or C++ is unavoidable, the best that developers can do to reduce the risk is to use managed buffers instead of raw pointers, which is the cause of the language’s vulnerability. For example, it’s better to type “std::string” in place of “char*” or <iostream> instead of <cstdio>. These strings of code make exceeding the buffer’s capacity impossible, among other benefits.
Otherwise, consider programming with less-vulnerable languages such as C#. Unlike C, C# can only employ raw pointers in unsafe mode, which should only be used to achieve specific results. C# also features safety mechanisms like the requirement of a .NET framework to be executable and Common Language Runtime garbage collection.
The good news is that modern systems have more protection from buffer overflows (though not completely immune) than in decades past. These include, but aren’t limited to:
- Data Execution Prevention (DEP): Built into Microsoft systems, DEP is a non-executable stack that marks selected portions of a computer’s memory strictly for data storage and processing. It will forbid executable actions from managing data using those portions, reducing the likelihood of a buffer overflow.
By default, DEP is on in Microsoft computers and devices and shouldn’t be turned off unless an incompatible program is running. The company also recommends hardware and software (Windows XP Service Pack 2 or later) that support DEP.
- Address Space Layout Randomization (ASLR): ASLR makes a buffer overflow much harder to pull off by moving address spaces to random locations in the buffer. This measure was developed in response to the downside of the more rigid DEP, especially for programs that utilize return-oriented programming.
ASLR was introduced into Microsoft systems, starting with Vista. Some experts believe that the Morris Worm may have been stopped had ASLR been a thing back then. ASLR is off by default but can be switched on in the security settings.
- Structured Exception Handler Overwrite Protection (SEHOP): SEHOP was developed to respond to SEH-based buffer overflow attacks, which exploit the function that catches and resolves hardware or software errors. However, this protection isn’t usually enabled due to the need to modify the registry, especially on Windows 7 and Server 2008 R2 systems.
Above all else, it pays to refrain from thinking you’re immune to buffer overflows. Many major businesses were only made aware of their vulnerability to them after several years, at which hackers might have gone off with their data under their noses. In this case, the solution is as simple as ensuring that every system is updated.
Conclusion
Although not as well-known as other cybersecurity threats, buffer overflow attacks are real and can cause businesses dearly. As discussed, the Phone Buffer Service vulnerability is one of the dozens of cases with the potential to steal personal information and leave users and service providers none the wiser.
It’s imperative for developers to be routinely aware of their code and choose the most suitable programming systems. Withstanding these attacks starts with preferring more resistant languages and code strings and ends with certifying the end product to be up to spec. Any resulting increase in overhead costs is a small price to pay in exchange for ensuring a safer online experience.
