There are three guarantees in life: death, taxes, and that software will have vulnerabilities. Through countless tests and studies, it has time and again been proven that for every thousand lines of code, there will be an average of between fifteen and fifty bugs or coding errors. According to the FBI, roughly 2% of these bugs can be exploited by an attacker. These are called vulnerabilities.
But, what exactly are software vulnerabilities, and why do they matter?
A software vulnerability is defined by the National Institute of Standard and Technology (NIST) as a weakness in an information system, system security procedures, internal controls, or an implementation that could be exploited or triggered by a threat source. Essentially, a software vulnerability is a bug or flaw in a system that an attacker can find and exploit to execute an attack against that system. Of these vulnerabilities, some of the most damaging are zero-day vulnerabilities. Zero-day vulnerabilities are newly discovered, have never been seen before, and are not yet patched. Without a security patch, there is nothing to stop an attacker from exploiting the vulnerability and waging a successful attack.
There is an average of 111 billion new lines of code being written every year, which means there are millions (actually 33,300,000 to 111,000,000) of opportunities for an attacker to turn those vulnerabilities into exploits.
CVEs, CWEs, and CVSS
To keep track of the vast amount of identified and unidentified vulnerabilities, the MITRE corporation created the Common Vulnerability and Exposures (CVE) database. This database provides a method to report, identify, and share data about publicly known software vulnerabilities.
In order to make sense of the thousands of vulnerabilities identified, MITRE introduced the Common Weaknesses Enumeration (CWE) list. Each CWE is a category into which CVEs are classified. Think of a CWE as being a bucket into which we pour some CVEs that are possible because of that CWE’s class of software flaws. To date, there are over 120 CWEs for categorizing the over 67,000 identified CVEs.
We should note that if you go to the CVE database you will see over 135,000 entries as of this writing. But since 2005 when the CWE list was associated with CVEs and entries are made by registered and vetted CVE numbering authorities, there have been only 67,000 of these high quality CVE entries.
Of course, not all CVEs are created equal. The level of potential impact a CVE could have on a system is measured by the Common Vulnerability Scoring System (CVSS). The CVSS provides a score between one and ten, with one being not at all severe and ten being the most severe. A CVE with a score of 7 or above can be thought of as ‘severe’.
Severity of a CVE is measured by a variety of factors. A severe CVE has these characteristics:
- Attack vector is from across a network (not through physical access)
- Attack complexity is low
- No special privilege or user interaction is required for the attack to succeed
- No workaround currently exists to prevent the attack from occurring.
While any vulnerability is a cause for concern, today we’re going to focus on the most common and severe types of vulnerabilities.
The above histogram illustrates all of the identified CVEs categorized by CWE. Let’s start with the first CWE on the left of the chart, Improper Restriction within the Bounds of a Memory Buffer (CWE-119), more commonly referred to as a ‘buffer overflow’.
- Buffer Overflows
In the most simple terms possible: a buffer is a region of computer memory used to temporarily store data while software is moving it from one place to another. A buffer overflow occurs when an instruction writes more data to a buffer than the buffer is designed to hold, forcing the data to “leak” into the adjacent buffer.
Not only are buffer overflows the most common type of vulnerability with over 12,000 identified CVEs, they are more often than not severe. MITRE has consistently ranked buffer overflows as the worst type of CWE. With the increasing adoption of embedded devices on the IoT, buffer overflow bugs are only getting worse.
Due to the commonality of buffer overflows, almost all cyberattacks start with one. Perhaps the most (in)famous attack that started with a buffer overflow is the 2009 Stuxnet attack. There is no shortage of analysis of Stuxnet (including by Dover), so we’ll take a high-level view of the attack.
Stuxnet was the first recorded weaponized cyberattack, widely accepted to be a joint effort between the United States and Israel. The attack targeted an Iranian nuclear power plant, and successfully infected the Siemens software, causing the destruction of dozens of nuclear centrifuges and significantly setting Iran’s nuclear program back.
While the Stuxnet attack was sophisticated, it all started with a simple buffer overflow. By preventing the exploitation of buffer overflows, a repeat-Stuxnet can entirely be avoided.
Dover’s CoreGuard technology prevents the exploitation of software vulnerabilities, including buffer overflows, effectively immunizing processors against entire classes of network-based attacks. CoreGuard acts as a bodyguard for a processor by monitoring every instruction executed to ensure that it complies with a set of predefined software rules, called micropolicies.
The micropolicy that prevents buffer overflow exploits, is our Heap micropolicy. The Heap micropolicy protects memory on the heap by assigning a color to the buffer where the data resides, as well as the pointer to that buffer. It then dictates that an instruction cannot write data to a buffer with a color that doesn’t match the color of the pointer to the buffer. If an attacker tries to exploit a buffer overflow by writing data to a non-matching buffer and pointer, CoreGuard issues a violation and stops that instruction from executing before any damage can be done.
2. Improper Input Validation
Improper Input Validation (CWE-20) is a class of weakness where the system is not required to validate input that affects the control flow or data flow of that program. When exploited, an attacker can manipulate the field in an otherwise normal input form, and then execute their own malicious code.
Mitigation of this type of vulnerability requires cooperation between the application and CoreGuar’s sanitization micropolicy. This means that developers should assume all input is malicious and use an "accept known good" input validation strategy. In other words, use a list of acceptable inputs that strictly conform to defined specifications and reject any input that does not strictly conform to those specifications or transform it into something that does.
Once such a sanitization routine is established, CoreGuard will guarantee that the routine is always called before the input data is used in any critical decision-making process. No attempt by the attacker to bypass the sanitization routine will be possible as the micropolicy rule requires that only correctly sanitized data may be used in the decision making function. So, if an attacker tries to bypass the sanitization routine or change data after the sanitization routine has completed, CoreGuard will issue a policy violation and block that data from being passed to the decision-making function.
3. Information Exposure
Information Exposure (CWE-200) attacks are common with just over 6,000 identified CVEs. Of these CVEs, only 206 are considered severe, but when these severe vulnerabilities are exploited, the consequences can be significant.
In 2017 a severe information disclosure vulnerability, CVE-2017-081 was identified in the Android media framework. The Android media includes support for playing a variety of common media types and enables developers to easily integrate audio, video, and images into their applications.
This vulnerability had a low level of complexity, would allow an attacker to take control of the system or execute a denial of service. This vulnerability was present in the Android multimedia framework, which includes support for media files like audio, video, and images on any Android device. While Android is one of the most popular mobile device operating systems, Android devices also include things like Smart TVs and entertainment devices. As of 2019 there were 2.5 billion active Android devices from over 180 manufacturers.
This particular vulnerability was considered severe because its attack vector was across the network, the attack complexity was low, it required no privileges or user interaction, and its impact on availability was high (took control of the system or resulted in a denial of service).
CoreGuard prevents data breaches that exploit this class of vulnerability like the by enforcing data confidentiality. The Confidentiality micropolicy ensures that data marked as “confidential” never leaves the device unless it is encrypted. Furthermore, if confidential data is in any way combined with public data, CoreGuard’s Confidentiality micropolicy prevents that combined data from being exfiltrated. We are able to achieve this level of data protection through taint-tracking.
CoreGuard’s confidentiality micropolicy would taint all confidential information (like a person’s age, birthdate or system status or internal configuration or even passwords) as ‘confidential’. Such tainted data is never allowed to leave the system unless it is encrypted first. This is accomplished by marking any ports or memory-mapped IO addresses with a metadata tag of ‘public’. Storing tainted data to any memory with a metadata tag of ‘public’ is a micropolicy violation and that instruction will not complete. The only privileged routine that can remove the ‘confidential’ taint is the encryption function. Once confidential data is encrypted it can safely be written outside the system.
4. SQL Injection
Rounding out the list of the most common types of software vulnerabilities is SQL injection (CWE-89), with 5,643 identified CVEs, over 4,000 of which are severe. SQL injection can occur when the software constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not sanitize or incorrectly sanitizes special elements that could modify the intended SQL command when it is sent to a downstream component (i.e. the database).
This comes from fundamental weaknesses in the SQL language. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data. This can be used to alter query logic to bypass security checks, or to insert additional statements that modify the back-end database, possibly including execution of system commands. SQL injection has become a common issue with database-driven web sites. The flaw is easily detected, and easily exploited, and as such, any site or software package with even a minimal user base is likely to be subject to an attempted attack of this kind.
In 2010, a severe vulnerability was found within Symantec Security Software that would allow an attacker to execute arbitrary SQL commands. This particular CVE, which scored a severity level of 7.5 and was eventually patched, would have been prevented from ever occurring with CoreGuard’s sanitization micropolicy. Still, the developer must thoughtfully create the right kind of sanitization routine to allow only the types of queries acceptable for that application. Having done so, CoreGuard’s sanitization micropolicy will guarantee that the only data allowed to drive the database engine will have been sanitized and not modified in any way prior to its use in the database.
Symantec is now known as NortonLifeLock and is a popular cybersecurity vendor. This particular vulnerability highlights the danger in relying solely on software cybersecurity solutions.
Like any other software, it too will have bugs and be vulnerable to cyberattacks. In addition to providing cybersecurity for systems, CoreGuard also reinforces the other cybersecurity software that may already be installed. In some cases, CoreGuard can even replace those existing software defenses.
Cybersecurity Should Not be Reactive
With new CVEs being discovered every day, it is critical to protect against classes of vulnerabilities. This proactive approach prevents even zero-day attacks from causing any damage. Dover’s CoreGuard technology protects against up to 94% of all software vulnerabilities—including both known and unknown CVEs.
The histogram above illustrates the level of protection provided by CoreGuard against the most common and severe types of software vulnerabilities. Software bugs are always going to be present in our systems, and bad actors are always going to want to exploit them. By preventing the exploitation of these software vulnerabilities, CoreGuard is immunizing processors to protect embedded systems from entire classes of network-based attacks.
While the software vulnerabilities reviewed in this post are just some of the most common, there are over 100 other categories of CVEs that may be of concern to you and your organization. To learn more about those categories and the level of protection CoreGuard can provide, request a copy of The Cybersecurity Scorecard White Paper here.