Back to Blog
Why Are Buffer Overflows So Dangerous?

buffer overflow blog img

We talk about buffer overflows a lot. So much so, it almost seems silly to be writing another article dedicated to this software vulnerability.  But, it’s worth driving the point home: buffer overflows are one of the most dangerous software vulnerabilities in embedded systems today. In fact, the MITRE Corporation ranked a buffer overflow as the most dangerous software weakness of 2021. So, here we are ready to break down the common buffer overflow and talk a little bit more about what makes it so dangerous.  

But first, the basics. Generally, there are two types of buffer overflows, stack-based and heap-based. The difference between the two types is simply the location of the overflow. A stack-based buffer overflow corrupts memory on the stack and impacts things like return addresses and local variables. A heap-based buffer overflow is an overflow on the heap portion of memory, and creates a scenario in which the buffer can be overwritten to the heap. 

One reason buffer overflows are so dangerous is that they are extremely common mistakes that software developers make, and the way to make them is incredibly varied. Under the umbrellas of heap and stack-based buffer overflows, there is even further granularity, including CWEs like Access of Memory Location After End of Buffer (CWE-788) and Out-of-bounds Write (CWE-787). The bottom line is that there are countless ways that a buffer overflow vulnerability can mistakenly be written into code, and software with millions (or even billions) of lines of code are bound to be ripe with these types of errors.

How Bad Actors Exploit Buffer Overflows to Attack Embedded Systems 

In addition to cataloging classes of vulnerabilities via the CWE database, MITRE also analyzes common attack patterns in their Common Attack Pattern Enumeration and Classification (CAPEC) database. MITRE created the CAPEC database to help developers better understand how potential adversaries can exploit vulnerabilities in code in order to execute an attack

If we take a look at CAPEC-100, which is classified as a simple buffer overflow attack, MITRE classifies it as having both a high likelihood of attack and a very high typical severity. Let’s take a look at how this type of attack would be executed.

There are three stages to every buffer overflow attack. The first stage is exploration. This is when an attacker identifies a buffer to target and determines an injection vector to deliver their malicious code or data. 

The second stage is experimentation. The attacker designs the data or code to be injected based on the desired outcome. For instance, if they want to crash the system, they could simply overload the buffer with a lot of random characters. However, if the attacker wishes to take control of the system, they would need to inject arbitrary code that overflows the targeted buffer. With that code injected, the attacker is able to overwrite the return address and replace it with a return address that points to the injected code. 

The final stage is the actual exploitation of the buffer overflow. This injection of arbitrary code enables the attacker to take control of the system or escalate privileges. The outcome of the successful exploitation of a buffer overflow all depends on the system being targeted and, of course, the intent of the attacker. 

The number of buffer overflow vulnerabilities is seemly infinite & it’s the most common initial attack vector

Buffer overflows play a part in the majority of cyberattacks, from attacks on critical infrastructure to massive data breaches. In fact, many infamous cyberattacks started with a buffer overflow, including Heartbleed, Operation Soft Cell, and Triton. Let’s take a look at a few of those, now. 

In 2018, a cyberattack dubbed Operation Soft Cell was discovered in the networks of major telecommunication providers, including T-Mobile, AT&T, and Vodafone. This attack was executed in multiple waves over the span of at least six years, totally undiscovered. Initially, the attackers exploited a buffer overflow vulnerability on the network infrastructure and then executed a code injection attack—giving them complete control over the network. Over six years, they were able to steal 100GB of private call record data on over 200 million entities, including call and messaging logs, device information, and even tower location data which could provide the physical location of the phone and its owner. 

While extremely costly, data breaches don’t typically have the potential for physical damage. However, the same cannot be said for critical infrastructure attacks—a method that we’ve seen grow in recent years. The 2017 Triton cyberattack, in particular, proved that remote attackers could not only produce a massive amount of physical damage, but also threaten the health and safety of human lives.

In the case of Triton, attackers exploited a buffer overflow in Schneider Electric’s Triconex SIS firmware, ultimately installing a Remote Access Trojan (RAT). Then they were able to exploit another software bug, this time a zero-day privilege-escalation vulnerability, which elevated the malware code to obtain read, write, and execute privileges. The attackers planned to inject further code to manipulate the speed of the components within the system and cause a dangerous explosion. Luckily, these attackers were unsuccessful, and an error in the attacker’s own code thwarted their plans.

Buffer overflows are around to stay (and wreak havoc on embedded systems)

The threat of buffer overflows corrupting embedded systems is not going away anytime soon. Just last month, multiple buffer overflow vulnerabilities were discovered in potentially millions of devices, including Programmable Logic Controllers. PLCs control various industrial processes in factories across the globe, and are responsible for controlling things like industrial automation systems, circuit breakers, and even lights and fans on the factory floor. 

While a patch is currently available to address these recently discovered vulnerabilities, installing patches is not an effective approach to security and can often be seen as a cumbersome task for organizations to implement. We’ve all gotten the notification mid-workday that it’s time to update your computer. Then you begin to think about how you’d have to close out of everything you’re working on, restart the computer, wait 10 minutes, if not longer, for it to install completely … so maybe you’ll just hit that “try again tomorrow” button, right?

Well, updating an embedded system, like a PLC, isn’t much different. Instead of waiting for 10 minutes for your laptop to restart, an organization needs to make the decision whether or not system operations would be significantly impacted by a temporary shutdown in order to install an update. Of course, the consequences of not updating your laptop immediately versus not updating a heavy-duty industrial automation system are vastly different. Still, more often than not, organizations do not update their software to install security patches as soon as they become available.  

According to a survey conducted by Google Research, only 35% of security experts ranked installing security patches in their top three methods to mitigating cyberattacks, and only 25% of security experts reported that they install security patches as soon as they are available to their organization. It’s clear that companies do not put much weight into security patches. So, even if the vendor is able to roll out a security patch immediately, odds are that the security patch will go uninstalled for some time. This gives attackers their opportunity to exploit the software vulnerability and execute an attack while it goes unpatched.

How to protect against the exploitation of buffer overflow vulnerabilities

If security patches are an insufficient and reactive approach to the problem, what’s the solution?

To address this problem, we need a defense mechanism that protects against the exploitation of entire classes of network-based attacks, including all buffer overflows. This is exactly what Dover’s CoreGuard solution is able to achieve. 

The CoreGuard technology acts as a bodyguard to the host processor and prevents the exploitation of all buffer overflows, including zero-day exploits. That means if a new buffer overflow vulnerability is discovered today, tomorrow or ten years from now, CoreGuard would be able to stop it from being exploited—no update or patch required.

CoreGuard’s Heap micropolicy protects memory on the heap by assigning a color to the buffer in which data resides, as well as to the pointer to the buffer. The Heap micropolicy then enforces that an instruction cannot write data to a buffer with a color that doesn’t match the pointer’s color. 

Meanwhile, CoreGuard’s Stack micropolicy protects frames on the stack, including the return address. An attacker attempting to exploit a buffer overflow to overwrite a return address would be unable to do so. CoreGuard would detect this attempt as an illegal instruction and stop it from executing, before any damage could be done. 

Eliminate the threat of buffer overflows with Dover’s CoreGuard Technology

Buffer overflows pose a threat not only to the systems they’re in, but to the health and safety of those living and working side-by-side with those systems. Security patches are insufficient and only address the vulnerabilities that have been discovered and likely already exploited. To top it off, 2021 has been a record-breaking year for zero-day exploits. Protecting against entire classes of attack rather than patching individual vulnerabilities (after the fact), needs to be a priority.

To learn more about Dover's CoreGuard technology and to see how CoreGuard prevents exploitation live, request a demo today.

Share This Post

More from Dover

PublishedOctober 05, 2021

In March 2021, Arm announced the release of its new Armv9 architecture. The first new architecture in a decade, Armv9 includes new security features—from compartmentalization to memory safety to pointer authentication.

Security CoreGuard Safety Privacy Defense-in-Depth