Description
This entry was deprecated because it overlapped the same concepts as race condition (CWE-362) and Improper Synchronization (CWE-662).
Modes of Introduction:
Related Weaknesses
Consequences
This entry was deprecated because it overlapped the same concepts as race condition (CWE-362) and Improper Synchronization (CWE-662).
Modes of Introduction:
The program sends non-cloned mutable data as an argument to a method or function.
The function or method that has been called can alter or delete the mutable data. This could violate assumptions that the calling function has made about its state. In situations where unknown code is called with references to mutable data, this external code could make changes to the data sent. If this data was not previously cloned, the modified data might not be valid in the context of execution.
Modes of Introduction:
– Implementation
Likelihood of Exploit: Medium
Integrity: Modify Memory
Potentially data could be tampered with by another function which should not have been tampered with.
Phase: Implementation
Description:
Pass in data which should not be altered as constant or immutable.
Phase: Implementation
Description:
Clone all mutable data before passing it into an external function . This is the preferred mitigation. This way, regardless of what changes are made to the data, a valid copy is retained for use by the class.
Sending non-cloned mutable data as a return value may result in that data being altered or deleted by the calling function.
In situations where functions return references to mutable data, it is possible that the external code which called the function may make changes to the data sent. If this data was not previously cloned, the class will then be using modified data which may violate assumptions about its internal state.
Modes of Introduction:
– Implementation
Likelihood of Exploit: Medium
Access Control, Integrity: Modify Memory
Potentially data could be tampered with by another function which should not have been tampered with.
Phase: Implementation
Description:
Declare returned data which should not be altered as constant or immutable.
Phase: Implementation
Description:
Clone all mutable data before returning references to it. This is the preferred mitigation. This way, regardless of what changes are made to the data, a valid copy is retained for use by the class.
A Pseudo-Random Number Generator (PRNG) is initialized from a predictable seed, such as the process ID or system time.
The use of predictable seeds significantly reduces the number of possible seeds that an attacker would need to test in order to predict which random numbers will be generated by the PRNG.
Modes of Introduction:
– Architecture and Design
Other: Varies by Context
Phase:
Description:
Use non-predictable inputs for seed generation.
Phase: Architecture and Design, Requirements
Description:
Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems, or use the more recent FIPS 140-3 [REF-1192] if possible.
Phase: Implementation
Description:
Use a PRNG that periodically re-seeds itself using input from high-quality sources, such as hardware devices with high entropy. However, do not re-seed too frequently, or else the entropy source might block.
The product uses a Pseudo-Random Number Generator (PRNG) in a security context, but the PRNG’s algorithm is not cryptographically strong.
Modes of Introduction:
– Architecture and Design
Likelihood of Exploit: Medium
Access Control: Bypass Protection Mechanism
If a PRNG is used for authentication and authorization, such as a session ID or a seed for generating a cryptographic key, then an attacker may be able to easily guess the ID or cryptographic key and gain access to restricted functionality.
Phase: Implementation
Description:
Use functions or hardware which use a hardware-based random number generation for all crypto. This is the recommended solution. Use CyptGenRandom on Windows, or hw_rand() on Linux.
A Pseudo-Random Number Generator (PRNG) uses a relatively small seed space, which makes it more susceptible to brute force attacks.
PRNGs are entirely deterministic once seeded, so it should be extremely difficult to guess the seed. If an attacker can collect the outputs of a PRNG and then brute force the seed by trying every possibility to see which seed matches the observed output, then the attacker will know the output of any subsequent calls to the PRNG. A small seed space implies that the attacker will have far fewer possible values to try to exhaust all possibilities.
Modes of Introduction:
– Architecture and Design
Other: Varies by Context
Phase: Architecture and Design
Description:
Use well vetted pseudo-random number generating algorithms with adequate length seeds. Pseudo-random number generators can produce predictable numbers if the generator is known and the seed can be guessed. A 256-bit seed is a good starting point for producing a “random enough” number.
Phase: Architecture and Design, Requirements
Description:
Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems, or use the more recent FIPS 140-3 [REF-1192] if possible.
The software uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize ‘….//’ (doubled dot dot slash) sequences that can resolve to a location that is outside of that directory.
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 uses a scheme that generates numbers or identifiers that are more predictable than required.
Modes of Introduction:
– Architecture and Design
Other: Varies by Context
A number or object is predictable based on observations that the attacker can make about the state of the system or network, such as time, process ID, etc.
Modes of Introduction:
– Architecture and Design
Other: Varies by Context
This weakness could be exploited by an attacker in a number ways depending on the context. If a predictable number is used to generate IDs or keys that are used within protection mechanisms, then an attacker could gain unauthorized access to the system. If predictable filenames are used for storing sensitive information, then an attacker might gain access to the system and may be able to gain access to the information in the file.
Phase: Implementation
Description:
Increase the entropy used to seed a PRNG.
Phase: Architecture and Design, Requirements
Description:
Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems. Consult FIPS 140-2 Annex C (“Approved Random Number Generators”).
Phase: Implementation
Description:
Use a PRNG that periodically re-seeds itself using input from high-quality sources, such as hardware devices with high entropy. However, do not re-seed too frequently, or else the entropy source might block.
An exact value or random number can be precisely predicted by observing previous values.
Modes of Introduction:
– Architecture and Design
Other: Varies by Context
Phase:
Description:
Increase the entropy used to seed a PRNG.
Phase: Architecture and Design, Requirements
Description:
Use products or modules that conform to FIPS 140-2 [REF-267] to avoid obvious entropy problems. Consult FIPS 140-2 Annex C (“Approved Random Number Generators”).
Phase: Implementation
Description:
Use a PRNG that periodically re-seeds itself using input from high-quality sources, such as hardware devices with high entropy. However, do not re-seed too frequently, or else the entropy source might block.