| Impact | Details |
|---|---|
|
Read Application Data; Bypass Protection Mechanism |
Scope: Confidentiality, Access Control
An attacker can gain access to sensitive information about the system, including authentication information that may allow an attacker to gain access to the system.
|
|
Read Application Data |
Scope: Confidentiality
When cryptographic primitives are vulnerable to side-channel-attacks, this could be used to reveal unencrypted plaintext in the worst case.
|
| Phase(s) | Mitigation |
|---|---|
|
Architecture and Design |
Strategy: Separation of Privilege Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges. |
|
Implementation |
Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not. |
| Nature | Type | ID | Name |
|---|---|---|---|
| ChildOf | Class 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. | 200 | Exposure of Sensitive Information to an Unauthorized Actor |
| ParentOf | Base 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. | 204 | Observable Response Discrepancy |
| ParentOf | Base 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. | 205 | Observable Behavioral Discrepancy |
| ParentOf | Base 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. | 208 | Observable Timing Discrepancy |
| ParentOf | Base 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. | 1300 | Improper Protection of Physical Side Channels |
| ParentOf | Base 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. | 1303 | Non-Transparent Sharing of Microarchitectural Resources |
| Nature | Type | ID | Name |
|---|---|---|---|
| ChildOf | Class 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. | 200 | Exposure of Sensitive Information to an Unauthorized Actor |
| Nature | Type | ID | Name |
|---|---|---|---|
| MemberOf | Category Category - a CWE entry that contains a set of other entries that share a common characteristic. | 1205 | Security Primitives and Cryptography Issues |
| ParentOf | Base 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. | 1300 | Improper Protection of Physical Side Channels |
| Phase | Note |
|---|---|
| Architecture and Design | |
| Implementation |
Class: Not Language-Specific (Undetermined Prevalence)
Class: Not Technology-Specific (Undetermined Prevalence)
Example 1
The following code checks validity of the supplied username and password and notifies the user of a successful or failed login.
In the above code, there are different messages for when an incorrect username is supplied, versus when the username is correct but the password is wrong. This difference enables a potential attacker to understand the state of the login function, and could allow an attacker to discover a valid username by trying different values until the incorrect password message is returned. In essence, this makes it easier for an attacker to obtain half of the necessary authentication credentials.
While this type of information may be helpful to a user, it is also useful to a potential attacker. In the above example, the message for both failed cases should be the same, such as:
Example 2
In this example, the attacker observes how long an authentication takes when the user types in the correct password.
When the attacker tries their own values, they can first try strings of various length. When they find a string of the right length, the computation will take a bit longer, because the for loop will run at least once. Additionally, with this code, the attacker can possibly learn one character of the password at a time, because when they guess the first character right, the computation will take longer than a wrong guesses. Such an attack can break even the most sophisticated password with a few hundred guesses.
Note that in this example, the actual password must be handled in constant time as far as the attacker is concerned, even if the actual password is of an unusual length. This is one reason why it is good to use an algorithm that, among other things, stores a seeded cryptographic one-way hash of the password, then compare the hashes, which will always be of the same length.
Example 3
Non-uniform processing time causes timing channel.
In the example above, an attacker may vary the inputs, then observe differences between processing times (since different plaintexts take different time). This could be used to infer information about the key.
Example 4
Suppose memory access patterns for an encryption routine are dependent on the secret key.
An attacker can recover the key by knowing if specific memory locations have been accessed or not. The value stored at those memory locations is irrelevant. The encryption routine's memory accesses will affect the state of the processor cache. If cache resources are shared across contexts, after the encryption routine completes, an attacker in different execution context can discover which memory locations the routine accessed by measuring the time it takes for their own memory accesses to complete.
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.
| Reference | Description |
|---|---|
|
Observable discrepancy in the RAPL interface for some Intel processors allows information disclosure.
|
|
|
Crypto hardware wallet's power consumption relates to total number of pixels illuminated, creating a side channel in the USB connection that allows attackers to determine secrets displayed such as PIN numbers and passwords
|
|
|
Java-oriented framework compares HMAC signatures using String.equals() instead of a constant-time algorithm, causing timing discrepancies
|
|
|
This, and others, use ".." attacks and monitor error responses, so there is overlap with directory traversal.
|
|
|
Enumeration of valid usernames based on inconsistent responses
|
|
|
Account number enumeration via inconsistent responses.
|
|
|
User enumeration via discrepancies in error messages.
|
|
|
User enumeration via discrepancies in error messages.
|
|
|
Bulletin Board displays different error messages when a user exists or not, which makes it easier for remote attackers to identify valid users and conduct a brute force password guessing attack.
|
|
|
Operating System, when direct remote login is disabled, displays a different message if the password is correct, which allows remote attackers to guess the password via brute force methods.
|
|
|
Product allows remote attackers to determine if a port is being filtered because the response packet TTL is different than the default TTL.
|
|
|
Product sets a different TTL when a port is being filtered than when it is not being filtered, which allows remote attackers to identify filtered ports by comparing TTLs.
|
|
|
Product modifies TCP/IP stack and ICMP error messages in unusual ways that show the product is in use.
|
|
|
Behavioral infoleak by responding to SYN-FIN packets.
|
|
|
Product may generate different responses than specified by the administrator, possibly leading to an information leak.
|
|
|
Version control system allows remote attackers to determine the existence of arbitrary files and directories via the -X command for an alternate history file, which causes different error messages to be returned.
|
|
|
FTP server generates an error message if the user name does not exist instead of prompting for a password, which allows remote attackers to determine valid usernames.
|
|
|
SSL implementation does not perform a MAC computation if an incorrect block cipher padding is used, which causes an information leak (timing discrepancy) that may make it easier to launch cryptographic attacks that rely on distinguishing between padding and MAC verification errors, possibly leading to extraction of the original plaintext, aka the "Vaudenay timing attack."
|
|
|
Virtual machine allows malicious web site operators to determine the existence of files on the client by measuring delays in the execution of the getSystemResource method.
|
|
|
Product uses a shorter timeout for a non-existent user than a valid user, which makes it easier for remote attackers to guess usernames and conduct brute force password guessing.
|
|
|
Product immediately sends an error message when a user does not exist, which allows remote attackers to determine valid usernames via a timing attack.
|
|
|
FTP server responds in a different amount of time when a given username exists, which allows remote attackers to identify valid usernames by timing the server response.
|
|
|
Browser allows remote attackers to determine the existence of arbitrary files by setting the src property to the target filename and using Javascript to determine if the web page immediately stops loading, which indicates whether the file exists or not.
|
| Nature | Type | ID | Name |
|---|---|---|---|
| MemberOf | CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. | 717 | OWASP Top Ten 2007 Category A6 - Information Leakage and Improper Error Handling |
| MemberOf | CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. | 728 | OWASP Top Ten 2004 Category A7 - Improper Error Handling |
| MemberOf | ViewView - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries). | 884 | CWE Cross-section |
| MemberOf | CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. | 967 | SFP Secondary Cluster: State Disclosure |
| MemberOf | CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. | 1417 | Comprehensive Categorization: Sensitive Information Exposure |
Rationale
This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.Comments
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.| Mapped Taxonomy Name | Node ID | Fit | Mapped Node Name |
|---|---|---|---|
| PLOVER | Discrepancy Information Leaks | ||
| OWASP Top Ten 2007 | A6 | CWE More Specific | Information Leakage and Improper Error Handling |
| OWASP Top Ten 2004 | A7 | CWE More Specific | Improper Error Handling |
| CAPEC-ID | Attack Pattern Name |
|---|---|
| CAPEC-189 | Black Box Reverse Engineering |
| Submissions | |||
|---|---|---|---|
| Submission Date | Submitter | Organization | |
|
2006年07月19日
(CWE Draft 3, 2006年07月19日) |
PLOVER | ||
| Contributions | |||
| Contribution Date | Contributor | Organization | |
| 2020年06月03日 | Nicole Fern | Cycuity (originally submitted as Tortuga Logic) | |
| Provided Demonstrative Example for cache timing attack | |||
| Modifications | |||
| Modification Date | Modifier | Organization | |
|
2025年04月03日
(CWE 4.17, 2025年04月03日) |
CWE Content Team | MITRE | |
| updated Demonstrative_Examples | |||
|
2024年02月29日
(CWE 4.14, 2024年02月29日) |
CWE Content Team | MITRE | |
| updated Demonstrative_Examples | |||
| 2023年10月26日 | CWE Content Team | MITRE | |
| updated Observed_Examples | |||
| 2023年06月29日 | CWE Content Team | MITRE | |
| updated Mapping_Notes | |||
| 2023年04月27日 | CWE Content Team | MITRE | |
| updated Relationships | |||
| 2021年10月28日 | CWE Content Team | MITRE | |
| updated Observed_Examples | |||
| 2021年07月20日 | CWE Content Team | MITRE | |
| updated Demonstrative_Examples | |||
| 2020年12月10日 | CWE Content Team | MITRE | |
| updated Common_Consequences, Demonstrative_Examples, Description, Name, Potential_Mitigations, Research_Gaps | |||
| 2020年08月20日 | CWE Content Team | MITRE | |
| updated Alternate_Terms, Common_Consequences, Demonstrative_Examples, Description, Name, Potential_Mitigations, Related_Attack_Patterns, Relationships, Research_Gaps | |||
| 2020年02月24日 | CWE Content Team | MITRE | |
| updated Alternate_Terms, Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Name, Observed_Examples, Relationships | |||
| 2019年06月20日 | CWE Content Team | MITRE | |
| updated Relationships, Type | |||
| 2017年11月08日 | CWE Content Team | MITRE | |
| updated Applicable_Platforms | |||
| 2014年07月30日 | CWE Content Team | MITRE | |
| updated Relationships | |||
| 2012年10月30日 | CWE Content Team | MITRE | |
| updated Potential_Mitigations | |||
| 2012年05月11日 | CWE Content Team | MITRE | |
| updated Common_Consequences, Demonstrative_Examples, Observed_Examples, Relationships | |||
| 2011年06月01日 | CWE Content Team | MITRE | |
| updated Common_Consequences | |||
| 2009年12月28日 | CWE Content Team | MITRE | |
| updated Description, Name | |||
| 2008年09月08日 | CWE Content Team | MITRE | |
| updated Relationships, Taxonomy_Mappings | |||
| 2008年07月01日 | Eric Dalci | Cigital | |
| updated Potential_Mitigations, Time_of_Introduction | |||
| Previous Entry Names | |||
| Change Date | Previous Entry Name | ||
| 2009年12月28日 | Discrepancy Information Leaks | ||
| 2020年02月24日 | Information Exposure Through Discrepancy | ||
| 2020年08月20日 | Observable Discrepancy | ||
| 2020年12月10日 | Observable Differences in Behavior to Error Inputs | ||
Use of the Common Weakness Enumeration (CWE™) and the associated references from this website are subject to the Terms of Use. CWE is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE). Copyright © 2006–2025, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation.