CWE

Common Weakness Enumeration

A Community-Developed List of Software & Hardware Weakness Types

2021 CWE Most Important Hardware Weaknesses
CWE Top 25 Most Dangerous Weaknesses
Home > CWE List > CWE- Individual Dictionary Definition (4.6)  
ID

CWE-1342: Information Exposure through Microarchitectural State after Transient Execution

Weakness ID: 1342
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
The processor does not properly clear microarchitectural state after incorrect microcode assists or speculative execution, resulting in transient execution.
+ Extended Description

In many processor architectures an exception, mis-speculation, or microcode assist results in a flush operation to clear results that are no longer required. This action prevents these results from influencing architectural state that is intended to be visible from software. However, traces of this transient execution may remain in microarchitectural buffers, resulting in a change in microarchitectural state that can expose sensitive information to an attacker using side-channel analysis. For example, Load Value Injection (LVI) [REF-1202] can exploit direct injection of erroneous values into intermediate load and store buffers.

Several conditions may need to be fulfilled for a successful attack:

  • 1) incorrect transient execution that results in remanence of sensitive information;
  • 2) attacker has the ability to provoke microarchitectural exceptions;
  • 3) operations and structures in victim code that can be exploited must be identified.
+ Relationships
Section HelpThis table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.226Sensitive Information in Resource Not Removed Before Reuse
Section HelpThis table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Hardware Design" (CWE-1194)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.1201Core and Compute Issues
ChildOfBaseBase - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.226Sensitive Information in Resource Not Removed Before Reuse
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
PhaseNote
Architecture and Design
Requirements
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Language-Independent (Undetermined Prevalence)

Operating Systems

Class: OS-Independent (Undetermined Prevalence)

Architectures

Class: Workstation (Undetermined Prevalence)

x86 (Undetermined Prevalence)

ARM (Undetermined Prevalence)

Other (Undetermined Prevalence)

Technologies

Class: Technology-Independent (Undetermined Prevalence)

Class: System on Chip (Undetermined Prevalence)

+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
ScopeImpactLikelihood
Confidentiality
Integrity

Technical Impact: Modify Memory; Read Memory; Execute Unauthorized Code or Commands

Medium
+ Demonstrative Examples

Example 1

Faulting loads in a victim domain may trigger incorrect transient forwarding, which leaves secret-dependent traces in the microarchitectural state. Consider this example from [REF-1203].

Consider the code gadget:

(bad code)
Example Language: Other 
void call_victim(size_t untrusted_arg) {
*arg_copy = untrusted_arg;
array[**trusted_ptr * 4096];
}

A processor with this weakness will store the value of untrusted_arg (which may be provided by an attacker) to the stack, which is trusted memory. Additionally, this store operation will save this value in some microarchitectural buffer, e.g. the store queue.

In this code gadget, trusted_ptr is dereferenced while the attacker forces a page fault. The faulting load causes the processor to mis-speculate by forwarding untrusted_arg as the (speculative) load result. The processor then uses untrusted_arg for the pointer dereference. After the fault has been handled and the load has been re-issued with the correct argument, secret-dependent information stored at the address of trusted_ptr remains in microarchitectural state and can be extracted by an attacker using a code gadget.

+ Observed Examples
ReferenceDescription
Load value injection in some processors utilizing speculative execution may allow an authenticated user to enable information disclosure via a side-channel with local access.
+ Potential Mitigations

Phases: Architecture and Design; Requirements

Hardware ensures that no illegal data flows from faulting micro-ops exists at the microarchitectural level.

Effectiveness: High

Note: Being implemented in silicon it is expected to fully address the known weaknesses with limited performance impact.

Phase: Build and Compilation

Include instructions that explicitly remove traces of unneeded computations from software interactions with microarchitectural elements e.g. lfence, sfence, mfence, clflush.

Effectiveness: High

Note: This effectively forces the processor to complete each memory access before moving on to the next operation. This may have a large performance impact.
+ Notes

Relationship

CWE-1342 differs from CWE-1303, which is related to misprediction and biasing microarchitectural components, while CWE-1342 addresses illegal data flows and retention. For example, Spectre is an instance of CWE-1303 biasing branch prediction to steer the transient execution indirectly.
+ References
[REF-1202] Jo Van Bulck, Daniel Moghimi, Michael Schwarz, Moritz Lipp, Marina Minkin, Daniel Genkin, Yuval Yarom, Berk Sunar, Daniel Gruss, and Frank Piessens. "LVI - Hijacking Transient Execution with Load Value Injection". 2020. <https://lviattack.eu/>.
[REF-1203] Jo Van Bulck, Daniel Moghimi, Michael Schwarz, Moritz Lipp, Marina Minkin, Daniel Genkin, Yuval Yarom, Berk Sunar, Daniel Gruss, and Frank Piessens. "LVI: Hijacking Transient Execution through Microarchitectural Load Value Injection". 2020-01-09. <https://lviattack.eu/lvi.pdf>.
[REF-1204] "Hijacking Transient Execution through Microarchitectural Load Value Injection". 2020-05-18. <https://www.youtube.com/watch?v=99kVz-YGi6Y>.
[REF-1205] Stephan van Schaik, Marina Minkin, Andrew Kwong, Daniel Genkin, Yuval Yarom. "CacheOut: Leaking Data on Intel CPUs via Cache Evictions". 2020-12-28. <https://cacheoutattack.com/files/CacheOut.pdf>.
+ Content History
+ Submissions
Submission DateSubmitterOrganization
2021-09-22Anders Nordstrom, Alric AlthoffTortuga Logic
More information is available — Please select a different filter.
Page Last Updated: October 26, 2021