Back to Blog
BadAlloc: The Latest Buffer Overflow Vulnerability Impacting the IoT

Screen Shot 2021-05-24 at 8.44.26 AMIt wasn’t too long ago that we wrote a roundup of the severe buffer overflow vulnerabilities discovered in the just the first quarter of 2021, but the all-too-common bug has made the news yet again. 

This time, a group of vulnerabilities called BadAlloc, named by the Microsoft research group that first identified them in April, has impacted potentially hundreds of millions of systems within major corporations, including Amazon, Google, Samsung, and Texas Instruments. 


BadAlloc found in major semiconductor manufacturers, impacting millions of devices

Of the 25 individual vulnerabilities identified, all of them fall under CWE-190. This category of vulnerability—integer overflow or wraparound—is a memory safety flaw that occurs when the software is programmed to perform a calculation in which the value is increased to a value that is too large to store in the associated buffer. If successfully exploited, these flaws will likely result in remote code injection—giving the attacker the potential to take control of the entire system. Due to the fact that these bugs can be remotely exploited and are fairly simple to attack, the Cybersecurity & Infrastructure Security Agency has classified the BadAlloc bugs as a 9.8 out of 10 on the vulnerability severity scale. 

Although no evidence was found to indicate that the vulnerabilities had been exploited, and the majority of companies impacted have already issued security patches, this serves as yet another cybersecurity wake up call.

Security patches are not a defense mechanism

Patching software is standard practice and the ability to do so is considered table stakes, however, it should not be considered a viable security defense. 

This is due to so many reasons. But, first and foremost, patch-and-pray is a reactive and retrospective approach to security. It only protects you against the bugs that you know about and the attacks that have happened in the past. It does absolutely nothing to protect you against undiscovered bugs or the attacks of the future. 

On average, it takes anywhere between 60-150 days from the point of discovery for a bug to be patched. On top of that, the responsibility of implementing that patch is entirely reliant on someone installing the deployed update—and aren’t we all conditioned to ignore those reminders day-after-day? In fact, according to a study by Ponemon Institute, 60% of the cyberattacks in 2019 were caused by the exploitation of unpatched vulnerabilities

There’s even the possibility that the recent ransomware attack on Colonial Pipeline that forced the temporary halt of all pipeline operations in May 2021 resulted from the exploitation of an old, unpatched bug in the software (it should be noted that this is unconfirmed and details about the initial attack vector are still kept under wraps at the time of this writing).


Why we need an oversight system to solve today’s cybersecurity problems

The danger of exploitable software vulnerabilities is not new and it’s not going away. It’s been top of mind for decades, and led the Department of Defense to recommend the implementation of an oversight system that monitors and guards the host processor all the way back in 1983. That’s when the cybersecurity guidelines, named the Trusted Computer System Evaluation Criteria (TCSEC)—also known as the Orange Book—was first published. 

When the concept of a hardware-based oversight system was first described, it was only theoretical. However, Dover’s CoreGuard solution is making it a reality. The CoreGuard oversight system consists of a combination of hardware and software. The hardware part is the silicon IP that sits next to the host processor on the SoC and monitors every instruction issued to and received by the processor. The CoreGuard hardware ensures that all instructions comply to a set of software rules, called micropolicies which are informed by metadata. The combination of the micropolicies and metadata together give CoreGuard the information it needs to distinguish between good and bad instructions. If an instruction violates a microplicy, CoreGuard issues a violation to the host and stops it from executing before any damage is done.

How the CoreGuard Oversight System protects against BadAlloc 

At the core of CoreGuard is our base set of micropolicies-—Heap, Read/Write/Execute (RWX), and Stack. These base micropolicies were designed because not only do they stop the exploitation of over the most common and severe types of vulnerabilities, including zero-days, they do not require alterations to be made to the application. Additional micropolicies can be added or updated at any time. For example, systems designed to go into smart cars (or any technology where AI/ML is being used), will likely want to add our AI Data Integrity micropolicy, which prevents the modification of data between digital signature authentication and the AI subsystem.

In the case of BadAlloc, any attempted buffer overflow exploitation and subsequent code injection attack would have been thwarted by our Heap and RWX micropolicies (included in base set). The Heap micropolicy enforces protection on heap blocks by assigning a color to each buffer where the data resides, as well as to the pointer of that buffer. It enforces that data cannot write to a buffer if the pointer’s color does not match that of the buffer. 

Meanwhile, RWX prevents subsequent code injection attacks by labeling regions of memory as being readable, writable, and/or executable. Any regions of memory that receive data from the network would only be labeled as readable or writable, but never executable. Labeling such regions as non-executable stops the injection and execution of any remote code.

In CoreGuard-protected embedded systems, buffer overflow vulnerabilities, like BadAlloc, are no longer a concern. CoreGuard is a proactive cybersecurity defense and it’s designed to stop entire categories of vulnerabilities—not just specific threats—including zero-days. That means whether it’s a buffer overflow vulnerability from 10 years ago, 5 seconds from now, or 20 years in the future, CoreGuard will stop it.

To learn more about CoreGuard and see how it blocks buffer overflow and code injection attacks live, request a demo today.


Share This Post