This entry was deprecated because it overlapped the same concepts as race condition (CWE-362) and Improper Synchronization (CWE-662).
Modes of Introduction:
The software does not properly determine which state it is in, causing it to assume it is in state X when in fact it is in state Y, causing it to perform incorrect operations in a security-relevant manner.
Modes of Introduction:
– Architecture and Design
Integrity, Other: Varies by Context, Unexpected State
The software does not check the revocation status of a certificate after its initial revocation check, which can cause the software to perform privileged actions even after the certificate is revoked at a later time.
If the revocation status of a certificate is not checked before each action that requires privileges, the system may be subject to a race condition. If a certificate is revoked after the initial check, all subsequent actions taken with the owner of the revoked certificate will lose all benefits guaranteed by the certificate. In fact, it is almost certain that the use of a revoked certificate indicates malicious activity.
Modes of Introduction:
– Architecture and Design
Likelihood of Exploit: Medium
CWE-299
CWE-296
CWE-297
CWE-298
Access Control: Gain Privileges or Assume Identity
Trust may be assigned to an entity who is not who it claims to be.
Integrity: Modify Application Data
Data from an untrusted (and possibly malicious) source may be integrated.
Confidentiality: Read Application Data
Data may be disclosed to an entity impersonating a trusted entity, resulting in information disclosure.
Phase: Architecture and Design
Description:
Ensure that certificates are checked for revoked status before each use of a protected resource. If the certificate is checked before each access of a protected resource, the delay subject to a possible race condition becomes almost negligible and significantly reduces the risk associated with this issue.
A software system that accepts input in the form of a slash absolute path (‘/absolute/pathname/here’) without appropriate validation can allow an attacker to traverse the file system to unintended locations or access arbitrary files.
Modes of Introduction:
– Implementation
Confidentiality, Integrity: Read Files or Directories, Modify Files or Directories
Phase: Implementation
Effectiveness: High
Description:
Phase: Implementation
Description:
Inputs should be decoded and canonicalized to the application’s current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
The product divides a value by zero.
This weakness typically occurs when an unexpected value is provided to the product, or if an error occurs that is not properly detected. It frequently occurs in calculations involving physical dimensions such as size, length, width, and height.
Modes of Introduction:
– Implementation
Likelihood of Exploit: Medium
CWE-682
CWE-682
CWE-682
CWE-682
Availability: DoS: Crash, Exit, or Restart
A Divide by Zero results in a crash.
A product performs a series of non-atomic actions to switch between contexts that cross privilege or other security boundaries, but a race condition allows an attacker to modify or misrepresent the product’s behavior during the switch.
This is commonly seen in web browser vulnerabilities in which the attacker can perform certain actions while the browser is transitioning from a trusted to an untrusted domain, or vice versa, and the browser performs the actions on one domain using the trust level and resources of the other domain.
Modes of Introduction:
– Architecture and Design
Integrity, Confidentiality: Modify Application Data, Read Application Data
The software checks the state of a resource before using that resource, but the resource’s state can change between the check and the use in a way that invalidates the results of the check. This can cause the software to perform invalid actions when the resource is in an unexpected state.
This weakness can be security-relevant when an attacker can influence the state of the resource between check and use. This can happen with shared resources such as files, memory, or even variables in multithreaded programs.
Modes of Introduction:
– Implementation
Likelihood of Exploit: Medium
Integrity, Other: Alter Execution Logic, Unexpected State
The attacker can gain access to otherwise unauthorized resources.
Integrity, Other: Modify Application Data, Modify Files or Directories, Modify Memory, Other
Race conditions such as this kind may be employed to gain read or write access to resources which are not normally readable or writable by the user in question.
Integrity, Other: Other
The resource in question, or other resources (through the corrupted one), may be changed in undesirable ways by a malicious user.
Non-Repudiation: Hide Activities
If a file or other resource is written in this method, as opposed to in a valid way, logging of the activity may not occur.
Non-Repudiation, Other: Other
In some cases it may be possible to delete files a malicious user might not otherwise have access to, such as log files.
Phase: Implementation
Description:
The most basic advice for TOCTOU vulnerabilities is to not perform a check before the use. This does not resolve the underlying issue of the execution of a function on a resource whose state and identity cannot be assured, but it does help to limit the false sense of security given by the check.
Phase: Implementation
Description:
When the file being altered is owned by the current user and group, set the effective gid and uid to that of the current user and group when executing this statement.
Phase: Architecture and Design
Description:
Limit the interleaving of operations on files from multiple processes.
Phase: Implementation, Architecture and Design
Description:
If you cannot perform operations atomically and you must share access to the resource between multiple processes or threads, then try to limit the amount of time (CPU cycles) between the check and use of the resource. This will not fix the problem, but it could make it more difficult for an attack to succeed.
Phase: Implementation
Description:
Recheck the resource after the use call to verify that the action was taken appropriately.
Phase: Architecture and Design
Description:
Ensure that some environmental locking mechanism can be used to protect resources effectively.
Phase: Implementation
Description:
Ensure that locking occurs before the check, as opposed to afterwards, such that the resource, as checked, is the same as it is when in use.
If two threads of execution use a resource simultaneously, there exists the possibility that resources may be used while invalid, in turn making the state of execution undefined.
Modes of Introduction:
– Architecture and Design
Likelihood of Exploit: Medium
Integrity, Other: Alter Execution Logic, Unexpected State
The main problem is that — if a lock is overcome — data could be altered in a bad state.
Phase: Architecture and Design
Description:
Use locking functionality. This is the recommended solution. Implement some form of locking mechanism around code which alters or reads persistent data in a multithreaded environment.
Phase: Architecture and Design
Description:
Create resource-locking validation checks. If no inherent locking mechanisms exist, use flags and signals to enforce your own blocking scheme when resources are being used by other threads of execution.
This entry has been deprecated. There are no documented cases in which a switch’s control expression is evaluated more than once.
It is likely that this entry was initially created based on a misinterpretation of the original source material. The original source intended to explain how switches could be unpredictable when using threads, if the control expressions used data or variables that could change between execution of different threads. That weakness is already covered by CWE-367. Despite the ambiguity in the documentation for some languages and compilers, in practice, they all evaluate the switch control expression only once. If future languages state that the code explicitly evaluates the control expression more than once, then this would not be a weakness, but the language performing as designed.
Modes of Introduction:
The software uses a signal handler that introduces a race condition.
Modes of Introduction:
– Architecture and Design
Likelihood of Exploit: Medium
CWE-362
CWE-415
CWE-416
CWE-123
Integrity, Confidentiality, Availability: Modify Application Data, Modify Memory, DoS: Crash, Exit, or Restart, Execute Unauthorized Code or Commands
It may be possible to cause data corruption and possibly execute arbitrary code by modifying global variables or data structures at unexpected times, violating the assumptions of code that uses this global data.
Access Control: Gain Privileges or Assume Identity
If a signal handler interrupts code that is executing with privileges, it may be possible that the signal handler will also be executed with elevated privileges, possibly making subsequent exploits more severe.
Phase: Requirements
Description:
Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
Phase: Architecture and Design
Description:
Design signal handlers to only set flags, rather than perform complex functionality. These flags can then be checked and acted upon within the main program loop.
Phase: Implementation
Description:
Only use reentrant functions within signal handlers. Also, use validation to ensure that state is consistent while performing asynchronous actions that affect the state of execution.