There has been a lot of press (rightly so) regarding the “Meltdown”- and “Spectre”-style attacks. The CWE and CAPEC teams have been reviewing the available information and trying to determine if new weaknesses or attack patterns should be added. Below are our current thoughts. We welcome additional discussion.

Common Weakness Enumeration (CWE™)

Both Meltdown and Spectre are technically attacks. They take advantage of a processor executing instructions out of order, in a way that causes some instructions to be executed even though the logic of the original code would not execute these instructions. This condition leads to a case where data in memory is cached before a permission check is performed. The end result is the ability to perform side-channel style attacks against the cache to learn the exact value of data.

The root cause of both of these attacks is the out of order execution. The processor uses this feature to increase the speed at which a program can be executed. This is very similar to compiler optimizations where a compiler makes changes to the source code to improve performance. In both instances, the computer is no longer executing exactly what the developer told it to execute, but rather is executing a variation that the processor/compiler thinks is “better.”

Unfortunately, these optimizations can sometimes lead to an exploitable weakness. There already exists a base-level CWE for the compiler version of this:

A new base-level CWE should be added to cover the case where the processor changes the order of security-critical code.

In addition, a new class-level CWE should also be considered around the topic of “Insecure Optimizations.” This class-level CWE would be a member of the Behavioral Problems category in the Development Concepts view, and a child of Interaction Error in the Researcher view. Both the existing compiler optimization (CWE-733) weakness and the new processor execution order weakness would be children of this new class.

Finally, there should be a CanFollow relationship between the existing class CWE-696: Incorrect Behavior Order and this new class “Insecure Optimizations”. We see this relationship in Meltdown/Spectre with the optimizations resulting in a change in the order of execution.

One last note, many discussions of Meltdown and Spectre focus on the side channel attack that arises from timing discrepancies. In this case, the timing discrepancy is not a weakness as it is legitimate behavior (since caching improves efficiency) and is not introduced by choices made by the application developer. Therefore, this is not a focus from the CWE classification perspective; the ability to see this (legitimate) timing discrepancy arises from the insecure optimization.

Common Attack Pattern Enumeration and Classification (CAPEC™)

Shifting to the attack pattern side of things, both the compiler and processor weaknesses are not currently well represented in CAPEC.

The compiler weakness (CWE-733) is not directly attacked, but rather results in a different weakness (e.g., buffer overflow) being present in the software, and that weakness is the one that is used in an attack. CWE thinks of this as a chain. The processor weakness can be thought of in the same way. Even though an adversary can manipulate when/how a processor decides to execute out of order, it is the resulting exposure of data that contributes to the vulnerability. See CWE-668: Exposure of Resource to Wrong Sphere.

For both the Meltdown and Spectre attacks, CAPEC already has a relevant standard-level attack pattern that can be leveraged:

This attack pattern has a detailed-level child that covers the DNS version of cache poisoning. Meltdown and Spectre expose a different type of cache poisoning where the adversary doesn't insert malicious data into the cache, but rather cause the cache to contain data that shouldn’t be allowed. CAPEC-141 needs to be cleaned up a bit, but the overall idea behind it is valid. A new detailed-level pattern should be added to cover the Flush+Reload attack pattern (and potentially others) that are leveraged by the Meltdown and Spectre attacks.

What do you think?

Please let us know your thoughts on the above by sending an email message to the CWE Researcher community discussion list, or directly to cwe@mitre.org.

CWE Version 3.0 has been posted on the CWE List page. A detailed report is available that lists specific changes between Version 2.11 and Version 3.0.

The main changes for CWE 3.0 include:

Views:

One new view was added, Architectural Concepts, which is based on work by the Rochester Institute of Technology. We thank them for their contributions. This new view organizes weaknesses according to common architectural security tactics, and is intended to assist architects in identifying potential weaknesses when designing software.

There were numerous refinements to the Development Concepts view, primarily focusing on simplifying the top-level categories and improving the relationships amongst the individual weaknesses within (this is ongoing work that will continue into 2018).

The Seven Pernicious Kingdoms view was updated to more closely align it to the original white paper on which it based, and to make it easier to use.

Made the <Weakness_Catalog> the only valid root element. Since the focus of CWE on weaknesses, make the <Weaknesses> child element required, while the other children (Views, Categories, and External_References) become optional.

Removed the <Compound_Element> and added a new "structure" attribute to <Weakness> element with values of: simple, chain, composite.

Added the <External_References> element to the weakness catalog that will function as a central collection of references that individual weaknesses can pull from as needed. As a side benefit, there is no longer a need to have a local reference ID as the main ID can be used.

Within the Applicable_Platform element, moved the CPE platform reference element to be an optional attribute on <Operating_System> because CPE is only applicable for the OS field and not languages, architectures, paradigms, or environments.

Changed the <Relationships> element to only be used for views and categories, and limited the values to memberOf and hasMember. As part of this, a new <Related_Weaknesses> element was added that holds all the different types of relationships that weaknesses can have with each other in order to eliminate the incorrect use memberOf and hasMember relationships with weaknesses, and the incorrect use of parentOf and childOf with views and categories.

Combined all the different note elements into a single <Notes> element. Also, to simplify the schema and have fewer elements in the resulting XML, added a type attribute that allows for a distinction between maintenance, platform, relationship, terminology, theoretical, and other.

Also, made minor modifications to the child elements of <View>, <Category>, and <Weakness>; renamed the <Description> top-level elements; and revised the StructuredTextType and added a new StructuredCodeType that leverages XHTML but includes a couple of existing attributes (language, nature).

One additional cyber security product has achieved the final stage of MITRE's formal
CWE Compatibility Program and is now officially
"CWE-Compatible." The product is now eligible to use the CWE-Compatible Product/Service logo, and a completed and reviewed
"CWE Compatibility Requirements Evaluation" questionnaire is posted for the product as part of the organization's listing on the
CWE-Compatible Products and Services page on the CWE Web site. A total of
48 products to-date have been recognized as officially compatible.

The following product is now registered as officially "CWE-Compatible":

Use of the official CWE-Compatible logo will allow system administrators and other security professionals to look for the logo when adopting SwA products and services for their enterprises and the compatibility process questionnaire will help end-users compare how different products and services satisfy the CWE compatibility requirements, and therefore which specific implementations are best for their networks and systems.

CWE 2.11 has one new entry and two deprecated entries. In all, 116 entries had important changes, primarily due to continued reorganization of the Development Concepts View (CWE-699), updated CAPEC mappings, and focused improvements on individual entries.

The main changes include: (1) relationship changes for 28 entries (mostly in the Development View); (2) updates to 52 entries to align with attack pattern mappings from the recently-released Common Attack Pattern Enumeration and Classification (CAPEC™) Version 2.10; (3) error fixes and improved completeness for many individual entries based on external feedback and internal quality review; and (4) small consistency changes to mitigations for 47 entries. The schema was updated to 5.4.3.

The CWE Privacy Policy was updated to notify users that cookies are now being used on the CWE website for the sole purpose of saving "Presentation Filter" and "Show Details" (previously "Mapping-Friendly") selections so users do not have to continuously update the filter to navigate the CWE List.

CWE is cited in an April 10, 2017 article on the DARPA website entitled “Baking Hack Resistance Directly into Hardware” as a major focus of DARPA’s new System Security Integrated Through Hardware and Firmware (SSITH) program.

As stated on the website, the purpose of the SSITH program is to "develop hardware design tools that provide security against hardware vulnerabilities that are exploited through software in Department of Defense (DoD) and commercial electronic systems. SSITH seeks to leverage current research in hardware design and software security to propel new research in the area of hardware security at the microarchitecture level."

CWE is mentioned in the article as follows: "SSITH specifically seeks to address the seven classes of hardware vulnerabilities listed in the Common Weakness Enumeration (cwe.mitre.org), a crowd-sourced compendium of security issues that is familiar to the information technology security community. In cyberjargon, these classes are: permissions and privileges, buffer errors, resource management, information leakage, numeric errors, crypto errors, and code injection. Researchers have documented some 2800 software breaches that have taken advantage of one or more of these hardware vulnerabilities, all seven of which are variously present to in the integrated microcircuitry of electronic systems around the world. Remove those hardware weaknesses … and you would effectively close down more than 40% of the software doors intruders now have available to them."

CWE is the focus of a section of the article entitled "CWE," in which the author describes what CWE is and how to use it and other tools to check code for weaknesses. The author also states: "Checking against various CWEs can also be a step toward achieving industry compliance. And CWEs can also be associated with common vulnerabilities and exposures (CVE), another intersection between quality and security."

CWE is mentioned again as the author concludes the article: "Producing software free of CWEs or CVEs makes it quality code. However, failure to maintain the code with the latest updates of its individual component and/or using fuzz testing to truly harden the code against future threats is vital. Both are necessary to have secure software applications."

CWE Version 2.10 has one new entry and one deprecated entry. In all, 127 entries had important changes, primarily due to reorganization of higher-level entries in the Development Concepts View (CWE-699), in order to simplify navigation of this view and reduce near-duplicate relationships. These changes were described in a post to the CWE Researcher email discussion list in late 2016, and are expected to continue in future CWE versions.

The main changes include: (1) relationship changes for 126 entries (mostly in the Development Concepts); (2) updates to 16 entries to align with attack pattern mappings from the recently-released Common Attack Pattern Enumeration and Classification (CAPEC™) Version 2.9; and (3) updated maintenance notes for 13 entries, primarily to identify Category entries that might be deprecated in the future as a result of the reorganization of the Development View. No changes were made to the schema.

We have updated the CWE website to streamline site navigation for an improved user experience. The main navigation menu is now located in an easy-to-access menu bar at the top of every page, with Section Contents menus for each section of the website just below the new main menu.

The main CWE List page has also been streamlined for ease-of-use into four main sections:

Navigate CWE – Offers two hierarchical representations, Research Concepts and Development Concepts, to help you navigate all weaknesses according to your specific point of view.

External Mappings – Offers views used to represent mappings to external groupings such as a Top-N list, as well as to express subsets of entries that are related by some external factor.

Helpful Views – Offers additional helpful views based on specific criteria and hopes to provide insight for a certain domain or use case, such as a specific source code language or phase of development.

One additional information security product has achieved the final stage of MITRE's formal
CWE Compatibility Program and is now officially
"CWE-Compatible." The product is now eligible to use the CWE-Compatible Product/Service logo, and a completed and reviewed
"CWE Compatibility Requirements Evaluation" questionnaire is posted for the product as part of the organization's listing on the
CWE-Compatible Products and Services page on the CWE Web site. A total of
45 products to-date have been recognized as officially compatible.

The following product is now registered as officially "CWE-Compatible":

Use of the official CWE-Compatible logo will allow system administrators and other security professionals to look for the logo when adopting SwA products and services for their enterprises and the compatibility process questionnaire will help end-users compare how different products and services satisfy the CWE compatibility requirements, and therefore which specific implementations are best for their networks and systems.

One additional information security product has achieved the final stage of MITRE's formal
CWE Compatibility Program and is now officially
"CWE-Compatible." The product is now eligible to use the CWE-Compatible Product/Service logo, and a completed and reviewed
"CWE Compatibility Requirements Evaluation" questionnaire is posted for the product as part of the organization's listing on the
CWE-Compatible Products and Services page on the CWE Web site. A total of
44 products to-date have been recognized as officially compatible.

The following product is now registered as officially "CWE-Compatible":

Use of the official CWE-Compatible logo will allow system administrators and other security professionals to look for the logo when adopting SwA products and services for their enterprises and the compatibility process questionnaire will help end-users compare how different products and services satisfy the CWE compatibility requirements, and therefore which specific implementations are best for their networks and systems.

Evenstar declared that its Code verification tool for ensuring source code compliance with domestic and international code security guidelines, BigLook, is CWE-Compatible. For additional information about this and other compatible products, visit the
CWE Compatibility and Effectiveness section.

One additional information security product has achieved the final stage of MITRE's formal
CWE Compatibility Program and is now officially
"CWE-Compatible." The product is now eligible to use the CWE-Compatible Product/Service logo, and a completed and reviewed
"CWE Compatibility Requirements Evaluation" questionnaire is posted for the product as part of the organization's listing on the
CWE-Compatible Products and Services page on the CWE Web site. A total of
43 products to-date have been recognized as officially compatible.

The following product is now registered as officially "CWE-Compatible":

Use of the official CWE-Compatible logo will allow system administrators and other security professionals to look for the logo when adopting SwA products and services for their enterprises and the compatibility process questionnaire will help end-users compare how different products and services satisfy the CWE compatibility requirements, and therefore which specific implementations are best for their networks and systems.