Vulnerability Mapping:ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review
(with careful review of mapping notes)
Abstraction:
ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers.For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts.For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers.For users who wish to see all available information for the CWE/CAPEC entry.For users who want to customize what details are displayed.
×
Edit Custom Filter
Description
The product uses a mechanism that automatically optimizes code, e.g. to improve a characteristic such as performance, but the optimizations can have an unintended side effect that might violate an intended security assumption.
Common Consequences
This 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.
Impact
Details
Alter Execution Logic
Scope: Integrity
The optimizations alter the order of execution resulting in side effects that were not intended by the original developer.
Relationships
This 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" (View-1000)
Nature
Type
ID
Name
ChildOf
Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.
Improper Interaction Between Multiple Correctly-Behaving Entities
ChildOf
Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.
Reliance on Undefined, Unspecified, or Implementation-Defined Behavior
ParentOf
Base - 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.
Compiler Optimization Removal or Modification of Security-critical Code
ParentOf
Base - 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.
Processor Optimization Removal or Modification of Security-critical Code
Modes
Of Introduction
The 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.
Phase
Note
Architecture and Design
Optimizations built into the design of a product can have unintended consequences during execution.
Applicable Platforms
This 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: Not Language-Specific
(Undetermined Prevalence)
Likelihood Of Exploit
Low
Demonstrative Examples
Example 1
The following code reads a password from the
user, uses the password to connect to a back-end
mainframe, and then attempts to scrub the password from
memory using memset().
(bad code)
Example Language: C
void GetData(char *MFAddr) {
char pwd[64];
if (GetPasswordFromUser(pwd, sizeof(pwd))) {
if (ConnectToMainframe(MFAddr, pwd)) {
// Interaction with mainframe
}
}
memset(pwd, 0, sizeof(pwd));
}
The code in the example will behave
correctly if it is executed verbatim, but if the code
is compiled using an optimizing compiler, then the call to
memset() might be removed as a dead store, because the
buffer pwd is not used after its value is overwritten.
Because the buffer pwd contains a sensitive
value, the application may be vulnerable to attack if
the data are left memory resident. If attackers are
able to access the correct region of memory, they may
use the recovered password to gain control of the
system.
It is common practice to overwrite sensitive
data manipulated in memory, such as passwords or
cryptographic keys, in order to prevent attackers from
learning system secrets. However, with the advent of
optimizing compilers, programs do not always behave as
their source code alone would suggest. In the example,
the compiler interprets the call to memset() as dead
code because the memory being written to is not
subsequently used, despite the fact that there is
clearly a security motivation for the operation to
occur. The problem here is that many compilers, and in
fact many programming languages, do not take this and
other security concerns into consideration in their
efforts to improve efficiency.
Attackers typically exploit this type of
vulnerability by using a core dump or runtime mechanism
to access the memory used by a particular application
and recover the secret information. Once an attacker
has access to the secret information, it is relatively
straightforward to further exploit the system and
possibly compromise other resources with which the
application interacts.
Selected Observed
Examples
Note: this is a curated list of examples for users to understand the variety of ways in which this
weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.
Intel, ARM, and AMD processor optimizations related to speculative execution and branch prediction cause access control checks to be bypassed when placing data into the cache. Often known as "Spectre".
C compiler optimization, as allowed by specifications, removes code that is used to perform checks to detect integer overflows.
Weakness Ordinalities
Ordinality
Description
Primary
(where the weakness exists independent of other weaknesses)
This weakness does not depend on other weaknesses and is the result of choices made during optimization.
Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that
reference this weakness as a member. This information is often useful in understanding where a
weakness fits within the context of external information sources.
Nature
Type
ID
Name
MemberOf
Category - a CWE entry that contains a set of other entries that share a common characteristic.
Description
This 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.
