Back to Blog
Stopping the Most Common CWE Threats in Embedded Systems



The threat universe for embedded systems is seemingly endless. To try to make sense of it all, we turn to MITRE’s CWE database. It’s a publicly-available, community-developed list of software and hardware weaknesses. Its purpose is to serve as a common language for security tools and be a baseline for weakness identification, mitigation, and prevention.

At a high-level, MITRE tracks two main things: Common Vulnerabilities & Exposures (CVEs) and Common Weakness Enumerations (CWEs). CVEs are specific vulnerabilities. You can think of them as specific cyberattacks—whether they are successfully executed or not. CWEs are categories of weaknesses, or types of bugs. When a CVE is added to the database, it must have a one and only one CWE category assigned to it. 

What that all means is there could be thousands of CVEs within a single CWE category. For instance, Heartbleed, a famous buffer overflow attack, is recorded as CVE-2014-0160 and it’s associated with CWE-787 Out-of-bounds Write. However, that vulnerability is just one of over 3,000 vulnerabilities attributed to CWE-787.

Understanding the Universe of Common Vulnerabilities

Now that you know there is this database of vulnerabilities and weaknesses, how do you use that information to understand the specific threats that are relevant to your company’s products? And how do you determine the appropriate mitigating defense mechanisms and determine their effectiveness against those specific threats? 

That’s where Dover’s Analytical Framework comes in. We take MITRE’s CWE database and label each CWE with an appropriate mitigating defense mechanism, if there is one. Then, solution providers that offer specific defense mechanisms can precisely calculate their level of protection by adding up all the CWEs that are labeled with their corresponding defense mechanism. 

Before jumping into the defense mechanisms, let’s look at a helpful depiction of MITRE’s universe of vulnerabilities and weaknesses.



Above is a histogram of MITRE’S universe of CWEs and CVEs. The CWEs are shown along the x-axis and CVEs are on the y-axis. In total, there are nearly 99,000 vulnerabilities, across 243 categories. The distribution clearly shows which types of vulnerabilities are most prevalent and, not surprisingly, cross site-scripting, buffer overflows, and SQL injection top the charts.

However, when assessing risk, it’s also important to consider severity. Individual CVEs are assigned a severity score, ranging from 0 to 10, with 10 being the most severe. In this graph, pink highlights the number of severe CVEs (those that score ≥ 7). They’re severe because the attack comes in over the network, is easy to execute, requires no special privilege, has no workaround, and adversely affects confidentiality, integrity, or availability. 

Ultimately, what this tells us is that CWEs with more pink, pose a greater threat. Let’s consider the top two CWEs, CWE-79 Cross-site Scripting and CWE-119 Improper Restriction of Operations within the Bounds of a Memory Buffer. Both CWEs have a high number of CVEs associated with them. However, more than two thirds of the vulnerabilities associated with CWE-119 are severe. While in the case of CWE-79, you can hardly see any pink on the bar because the number is so small (only 35 vulnerabilities). This means stopping CWE-119 (buffer overflow) is more important and has bigger impact than stopping CWE-79 (cross-site scripting)

Using Dover’s Analytical Framework to Identify Mitigating Defense Mechanisms

In order to make this database of vulnerabilities actionable, we organized them by defense mechanism. Without this organization, it would feel like an insurmountable task to protect against 99,000 individual vulnerabilities or even 243 different types of weaknesses. By grouping the CWEs based on defense mechanisms, it allows you to better identify the appropriate mix of security defenses necessary to protect your system.



The different defense mechanisms include, memory safety, sanitization, web protection, access control, privacy, and cryptography. Memory safety protects against any vulnerabilities related to memory access, including buffer overflows and dangling pointers. Sanitization ensures inputs are validated to protect downstream processing against attacks like SQL injection. Web protection enforces HTML sanitization, as well as processing of URLs and HTTP constructs.

Other mechanisms include access control which authenticates user identity and establishes user permissions, as well as privacy and cryptography which both ensure data privacy. Lastly, there is a small group of CWEs which have no defense mechanism at all. Generally, this represents vulnerabilities that are related to the way that the software was architected or configured, as well as vulnerabilities that occur as a result of user error. These can only be addressed on a case-by-case basis. 

Historically, most cybersecurity defense mechanisms have been implemented in software. However, we all know that a software-only approach doesn’t work. That’s because all software—including cybersecurity software—is inherently flawed. According to Steve McConnell, author of Code Complete, there are 15 to 50 bugs per thousand lines of source code. And those bugs translate to potentially hundreds of thousands of vulnerabilities that attackers can exploit to take over your system.

For true security, an embedded system needs a defense-in-depth approach that offers multiple layers of defense mechanisms—in particular, hardware-based mechanisms because hardware cannot be subverted or altered over the network.

That’s where Dover’s CoreGuard solution comes in—it’s a hardware-based defense mechanism that’s specifically designed to stop the exploitation of entire categories of software vulnerabilities.

How Dover’s CoreGuard® Stops the Most Common & Severe CWEs

CoreGuard is an oversight system that acts as a bodyguard to embedded systems, watching every instruction executed to ensure it complies with a set of security, safety, and privacy rules. It consists of both hardware and software components. The hardware is our silicon IP that directly integrates with the host processor. Because it resides in hardware, CoreGuard is unassailable by network-based cyberattacks, and it’s able to run at hardware speeds, providing real-time protection.

The software portion of the solution is broken up into two parts. The first is a set of rules, called micropolicies. Micropolicies are used to define the security, safety, and privacy properties that should be enforced. CoreGuard comes with a base set of micropolicies which stop the most common and severe types of attacks that plague any system, regardless of industry, including, buffer overflow, stack smashing, and code injection attacks. The second software component is metadata, which is information about every piece of data and every instruction in the application that is executed by the host.

If the host processor attempts to execute an instruction that violates a micropolicy, CoreGuard issues a violation exception back to the host and stops that instruction from executing before any damage can be done.

Returning to that universe of vulnerabilities, let’s see how the CoreGuard oversight system stacks up. 



Of the nearly 99,000 vulnerabilities, Dover’s CoreGuard protects against the exploitation of 93% of them. As you can see, the only remaining defense mechanism is cryptography—which is available from numerous vendors. The rest have no defense mechanism and have to be handled on a case-by-case basis, as I mentioned before. 

It’s important to note the CVEs on this graph only represent those vulnerabilities we know about and have been tracked by MITRE. That likely represents only a fraction of all bugs in the wild. Luckily, CoreGuard micropolicies are designed to block entire classes of attack and not just specific attacks. That means if there is a new buffer overflow vulnerability, for example, discovered today, tomorrow, or ten years from now, CoreGuard would stop it, no updates necessary.

Now, let’s look at few use case examples.

CWE-121: Stack-based Buffer Overflow

The first use case that I wanted to highlight is focused on one of the newest additions to the CWE database: CWE-121 Stack-based Buffer Overflow. The exploitation of this type of vulnerability can enable an attacker to execute a Return-oriented Programming (ROP) attack.

Earlier this year, multiple stack-based buffer overflow vulnerabilities were found in the management interface of some of Cisco’s wireless routers. This vulnerability could allow an authenticated, remote attacker to execute arbitrary code, or cause an affected device to restart unexpectedly. Ultimately, this could be used to execute a Denial-of-Service attack, not dissimilar to the Dyn attack of 2016 which brought down major sites, like Netflix and Twitter.

The defense mechanism for a vulnerability like this is CoreGuard’s Stack micropolicy, which is a memory safety rule. CoreGuard’s Stack micropolicy is designed to protect the control structure of a stack frame from being overwritten. During a ROP attack, the attacker will write more data to a stack buffer than it’s designed to hold and overwrite the function’s return address with a specific address that points to other code in memory that the program was not intended to execute. By modifying the return address, the attacker can hijack a program to execute system-level commands that delete files, change passwords, or even shut down servers.

With the Stack micropolicy in place, CoreGuard uses metadata, gathered at compile time, to tag a function’s code and its data on the stack. It then blocks any instructions that attempt to violate the structure of the stack frame and thus prevents ROP attacks.

CWE-89 SQL Injection

The second use case is CWE-89 SQL Injection. In an SQL injection attack, data from outside the system is used to construct a command that is sent to a back-end database or data processing engine. If the incoming data is not sent through a sanitization routine, potentially harmful commands can be sent to the database.

In 2013, the US Office of Personnel Management suffered a cyberattack in which a group of attackers infiltrated the core database servers operated by the OPM. These servers manage the records of all government employees and contain extremely personal information pertaining to security clearances. This information includes things like social security numbers, financial histories, relatives' names, and past residences. The attackers executed multiple breaches, including stealing user credentials for the background check system and installing malware via SQL injection to create a backdoor.

The attackers were in the OPM network for at least 2 years before being discovered. Nearly 22 million people were affected, including 5.6 million of whom also had their fingerprints stolen. The cost in credit monitoring services alone is ongoing and could reach as much as $1 billion.

The defense mechanism for an attack like this is a high-quality sanitization routine, paired with CoreGuard’s Sanitization micropolicy to ensure the routine can never be bypassed. The micropolicy does this using metadata to taint “trusted” vs. “untrusted” data and follow that through computation.

The micropolicy taints data from the outside world as ”untrusted.” The rule then says that only a distinguished sanitization function can change the “untrusted” taint to “trusted.” Lastly, the rule designates only data which is tainted “trusted” can enter the data processing engine—meaning only data that has gone through the sanitization routine can be processed.

If there is an attempt to exploit a bug that forgot to call sanitization and go straight to the data processing engine, that data will still be tainted as “untrusted” and thus CoreGuard will issue a violation and stop it from executing before any damage is done.

Spear Phishing

For the final use case, I wanted to consider a scenario in which the attacker uses a technique that is unrelated to a vulnerability or type of weakness. It is instead an example of user error—in this case I’m talking about spear phishing. You can’t completely stop phishing attacks from happening because no matter how much training you provide, you can’t guarantee that someone in your organization will never click on a malicious link. 

This is where a defense-in-depth approach comes in. Defense-in-depth means having multiple layers of security which will stop follow-on attacks, if something else fails along the way, like an employee mistakenly clicking on a bad link. 

In 2014, an attacker infiltrated a steel manufacturing facility in Germany via a spear phishing email sent to industrial operators. From there, they were able to take over the plant’s industrial control system and cause multiple components to fail. Most notably it caused a furnace to be shut down improperly. This was particularly problematic because a blast furnace must follow a very specific blow down process—or set of steps—to properly and safely shut down. In this case, attackers forced the furnace into an unregulated shutdown which resulted in massive physical damage.

This damage could have been prevented had CoreGuard’s Finite State Machine micropolicy been in place. This micropolicy ensures the proper functioning of safety critical finite state machine systems, like a blast furnace. It works by defining the safe states of a system and enforcing only the allowed transitions from one safe state to the next. As a result, CoreGuard can stop attacks that attempt to circumvent the safety protocols of a finite state machine, which in an industrial environment can result in danger to life and catastrophic physical damage.

CoreGuard ensures safety protocols by tracking, through metadata, the current state, as well as each transition routine. If an attacker is looking to cause serious damage, their goal would be to skip over the safe shutdown procedures. CoreGuard prevents this from happening with a simple rule that cross-checks each transition against the current state of the system. If the instruction is trying to jump to an out of order transition, CoreGuard will stop it from executing and issue a violation to the host.

Hardware-Based, Defense-in-Depth is Essential when Designing Embedded Systems

The cyber threats plaguing today’s embedded systems are only going to become more dangerous, costly, and pervasive as time goes on. Trying to address those threats with a software-only security approach is both insufficient and ineffective. For true security, we need to employ hardware-based defense mechanisms because hardware cannot be subverted over the network. 

To learn more about our analytical framework and the level of protection that our hardware-based CoreGuard solution provides, download our CoreGuard Cybersecurity Scorecard.

Share This Post

More from Dover

PublishedNovember 04, 2021

In recent years, we have seen a significant rise in attacks on firmware.  A survey conducted by Microsoft concluded that in the last four years, there has been a 500% increase in reported firmware attacks, and 83% of surveyed businesses reported...