deardaniel/secdata-raw huggingface dataset:
CWE-335: Incorrect Usage of Seeds in Pseudo-Random Number Generator (PRNG)

Description:
The product uses a Pseudo-Random Number Generator (PRNG) but does not correctly manage seeds.

Extended Description:
PRNGs are deterministic and, while their output appears
		   random, they cannot actually create entropy. They rely on
		   cryptographically secure and unique seeds for entropy so
		   proper seeding is critical to the secure operation of the
		   PRNG. 
		    
		   Management of seeds could be broken down into two main areas:
		    
		    
			  
		   (1) protecting seeds as cryptographic material (such as a cryptographic key);
			  
			  
		   (2) whenever possible, using a uniquely generated seed from
		   a cryptographically secure source
			  
		    
			  
			   PRNGs require a seed as input to generate a stream of
			   numbers that are functionally indistinguishable from
			   random numbers.  While the output is, in many cases,
			   sufficient for cryptographic uses, the output of any
			   PRNG is directly determined by the seed provided as
			   input. If the seed can be ascertained by a third party,
			   the entire output of the PRNG can be made known to
			   them. As suc

Affected languages: Not Language-Specific
Parent weaknesses: CWE-330, CWE-330

Consequences:
  - Access Control: Bypass Protection Mechanism

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Demonstrative examples:
The following code uses a statistical PRNG to generate account IDs.
Because the program uses the same seed value for every invocation of the PRNG, its values are predictable, making the system vulnerable to attack.
private static final long SEED =[PII_REDACTED]; public int generateAccountID() { Random random = new Random(SEED); return random.nextInt(); }

Both of these examples use a statistical PRNG seeded with the current value of the system clock to generate a random number:
An attacker can easily predict the seed used by these PRNGs, and so also predict the stream of random numbers generated. Note these examples also exhibit CWE-338 (Use of Cryptographically Weak PRNG).
Random random = new Random(System.currentTimeMillis()); int accountID = random.nextInt();
srand(time()); int randNum = rand();

Real-world examples:
  - CVE-2020-7010: Cloud application on Kubernetes generates passwords using a weak random number generator based on deployment time.
  - CVE-2019-11495: server uses erlang:now() to seed the PRNG, which
			 results in a small search space for potential random
			 seeds
  - CVE-2018-12520: Product's PRNG is not seeded for the generation of session IDs
  - CVE-2016-10180: Router's PIN generation is based on rand(time(0)) seeding.
CWE-336: Same Seed in Pseudo-Random Number Generator (PRNG)

Description:
A Pseudo-Random Number Generator (PRNG) uses the same seed each time the product is initialized.

Extended Description:
Given the deterministic nature of PRNGs, using the same seed for each initialization will lead to the same output in the same order. If an attacker can guess (or knows) the seed, then the attacker may be able to determine the random numbers that will be produced from the PRNG.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-335

Consequences:
  - Other: Other

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Mitigations:
  - [Architecture and Design] Do not reuse PRNG seeds. Consider a PRNG that periodically re-seeds itself as needed from a high quality pseudo-random output, such as hardware devices.
  - [Architecture and Design] 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.

Demonstrative examples:
The following code uses a statistical PRNG to generate account IDs.
Because the program uses the same seed value for every invocation of the PRNG, its values are predictable, making the system vulnerable to attack.
private static final long SEED =[PII_REDACTED]; public int generateAccountID() { Random random = new Random(SEED); return random.nextInt(); }

This code attempts to generate a unique random identifier for a user's session.
Because the seed for the PRNG is always the user's ID, the session ID will always be the same. An attacker could thus predict any user's session ID and potentially hijack the session.
function generateSessionID($userID){ srand($userID); return rand(); }

Real-world examples:
  - CVE-2022-39218: SDK for JavaScript app builder for serverless code uses the same fixed seed for a PRNG, allowing cryptography bypass
CWE-337: Predictable Seed in Pseudo-Random Number Generator (PRNG)

Description:
A Pseudo-Random Number Generator (PRNG) is initialized from a predictable seed, such as the process ID or system time.

Extended Description:
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.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-335

Consequences:
  - Other: Varies by Context

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Mitigations:
  - Use non-predictable inputs for seed generation.
  - [Architecture and Design] 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.
  - [Implementation] 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.

Demonstrative examples:
Both of these examples use a statistical PRNG seeded with the current value of the system clock to generate a random number:
An attacker can easily predict the seed used by these PRNGs, and so also predict the stream of random numbers generated. Note these examples also exhibit CWE-338 (Use of Cryptographically Weak PRNG).
Random random = new Random(System.currentTimeMillis()); int accountID = random.nextInt();
srand(time()); int randNum = rand();

Real-world examples:
  - CVE-2020-7010: Cloud application on Kubernetes generates passwords using a weak random number generator based on deployment time.
  - CVE-2019-11495: server uses erlang:now() to seed the PRNG, which
			 results in a small search space for potential random
			 seeds
  - CVE-2008-0166: The removal of a couple lines of code caused Debian's OpenSSL Package to only use the current process ID for seeding a PRNG
  - CVE-2016-10180: Router's PIN generation is based on rand(time(0)) seeding.
  - CVE-2018-9057: cloud provider product uses a non-cryptographically secure PRNG and seeds it with the current time
CWE-338: Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG)

Description:
The product uses a Pseudo-Random Number Generator (PRNG) in a security context, but the PRNG's algorithm is not cryptographically strong.

Extended Description:
When a non-cryptographic PRNG is used in a cryptographic context, it can expose the cryptography to certain types of attacks. 
             Often a pseudo-random number generator (PRNG) is not designed for cryptography. Sometimes a mediocre source of randomness is sufficient or preferable for algorithms that use random numbers. Weak generators generally take less processing power and/or do not use the precious, finite, entropy sources on a system. While such PRNGs might have very useful features, these same features could be used to break the cryptography.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-330, CWE-330

Consequences:
  - Access Control: Bypass Protection Mechanism

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Mitigations:
  - [Implementation] 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.

Demonstrative examples:
Both of these examples use a statistical PRNG seeded with the current value of the system clock to generate a random number:
The random number functions used in these examples, rand() and Random.nextInt(), are not considered cryptographically strong. An attacker may be able to predict the random numbers generated by these functions. Note that these example also exhibit CWE-337 (Predictable Seed in PRNG).
Random random = new Random(System.currentTimeMillis()); int accountID = random.nextInt();
srand(time()); int randNum = rand();

Real-world examples:
  - CVE-2021-3692: PHP framework uses mt_rand() function (Marsenne Twister) when generating tokens
  - CVE-2009-3278: Crypto product uses rand() library function to generate a recovery key, making it easier to conduct brute force attacks.
  - CVE-2009-3238: Random number generator can repeatedly generate the same value.
  - CVE-2009-2367: Web application generates predictable session IDs, allowing session hijacking.
  - CVE-2008-0166: SSL library uses a weak random number generator that only generates 65,536 unique keys.
CWE-339: Small Seed Space in PRNG

Description:
A Pseudo-Random Number Generator (PRNG) uses a relatively small seed space, which makes it more susceptible to brute force attacks.

Extended Description:
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.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-335

Consequences:
  - Other: Varies by Context

Mitigations:
  - [Architecture and Design] 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.
  - [Architecture and Design] 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.

Demonstrative examples:
This code grabs some random bytes and uses them for a seed in a PRNG, in order to generate a new cryptographic key.
Since only 2 bytes are used as a seed, an attacker will only need to guess 2^16 (65,536) values before being able to replicate the state of the PRNG.
# getting 2 bytes of randomness for the seeding the PRNG  
				 seed = os.urandom(2) 
				 random.seed(a=seed) 
				 key = random.getrandbits(128)

Real-world examples:
  - CVE-2019-10908: product generates passwords via org.apache.commons.lang.RandomStringUtils, which uses java.util.Random internally. This PRNG has only a 48-bit seed.
CWE-34: Path Traversal: '....//'

Description:
The product 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.

Extended Description:
This allows attackers to traverse the file system to access files or directories that are outside of the restricted directory. 
             The '....//' manipulation is useful for bypassing some path traversal protection schemes. If "../" is filtered in a sequential fashion, as done by some regular expression engines, then "....//" can collapse into the "../" unsafe value (CWE-182). It could also be useful when ".." is removed, if the operating system treats "//" and "/" as equivalent.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-23

Consequences:
  - Confidentiality: Read Files or Directories

Detection methods:
  - Automated Static Analysis - Source Code: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             
  - Architecture or Design Review: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Highly cost effective: 
                         
                           

Mitigations:
  - [Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. 
                   When pe
  - [Implementation] 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 i

Real-world examples:
  - CVE-2004-1670: Mail server allows remote attackers to create arbitrary directories via a ".." or rename arbitrary files via a "....//" in user supplied parameters.
CWE-340: Generation of Predictable Numbers or Identifiers

Description:
The product uses a scheme that generates numbers or identifiers that are more predictable than required.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-330

Consequences:
  - Other: Varies by Context

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Demonstrative examples:
This code generates a unique random identifier for a user's session.
Because the seed for the PRNG is always the user's ID, the session ID will always be the same. An attacker could thus predict any user's session ID and potentially hijack the session.
function generateSessionID($userID){ srand($userID); return rand(); }

Real-world examples:
  - CVE-2022-29330: Product for administering PBX systems uses predictable identifiers and timestamps for filenames (CWE-340) which allows attackers to access files via direct request (CWE-425).
  - CVE-2001-1141: PRNG allows attackers to use the output of small PRNG requests to determine the internal state information, which could be used by attackers to predict future pseudo-random numbers.
  - CVE-1999-0074: Listening TCP ports are sequentially allocated, allowing spoofing attacks.
CWE-341: Predictable from Observable State

Description:
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.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-340

Consequences:
  - Other: Varies by Context

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Mitigations:
  - [Implementation] Increase the entropy used to seed a PRNG.
  - [Architecture and Design] 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").
  - [Implementation] 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.

Demonstrative examples:
This code generates a unique random identifier for a user's session.
Because the seed for the PRNG is always the user's ID, the session ID will always be the same. An attacker could thus predict any user's session ID and potentially hijack the session.
function generateSessionID($userID){ srand($userID); return rand(); }

Real-world examples:
  - CVE-2024-48445: Chain: e-commerce app relies on an easily-guessable timestamp (CWE-341) in a weak authentication algorithm (CWE-1390)
  - CVE-2002-0389: Mail server stores private mail messages with predictable filenames in a world-executable directory, which allows local users to read private mailing list archives.
  - CVE-2001-1141: PRNG allows attackers to use the output of small PRNG requests to determine the internal state information, which could be used by attackers to predict future pseudo-random numbers.
  - CVE-2000-0335: DNS resolver library uses predictable IDs, which allows a local attacker to spoof DNS query results.
  - CVE-2005-1636: MFV. predictable filename and insecure permissions allows file modification to execute SQL queries.
CWE-342: Predictable Exact Value from Previous Values

Description:
An exact value or random number can be precisely predicted by observing previous values.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-340

Consequences:
  - Other: Varies by Context

Mitigations:
  - Increase the entropy used to seed a PRNG.
  - [Architecture and Design] 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").
  - [Implementation] 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.

Real-world examples:
  - CVE-2002-1463: Firewall generates easily predictable initial sequence numbers (ISN), which allows remote attackers to spoof connections.
  - CVE-1999-0074: Listening TCP ports are sequentially allocated, allowing spoofing attacks.
  - CVE-1999-0077: Predictable TCP sequence numbers allow spoofing.
  - CVE-2000-0335: DNS resolver uses predictable IDs, allowing a local user to spoof DNS query results.
CWE-343: Predictable Value Range from Previous Values

Description:
The product's random number generator produces a series of values which, when observed, can be used to infer a relatively small range of possibilities for the next value that could be generated.

Extended Description:
The output of a random number generator should not be predictable based on observations of previous values. In some cases, an attacker cannot predict the exact value that will be produced next, but can narrow down the possibilities significantly. This reduces the amount of effort to perform a brute force attack. For example, suppose the product generates random numbers between 1 and 100, but it always produces a larger value until it reaches 100. If the generator produces an 80, then the attacker knows that the next value will be somewhere between 81 and 100. Instead of 100 possibilities, the attacker only needs to consider 20.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-340

Consequences:
  - Other: Varies by Context

Mitigations:
  - Increase the entropy used to seed a PRNG.
  - [Architecture and Design] 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").
  - [Implementation] 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.
CWE-344: Use of Invariant Value in Dynamically Changing Context

Description:
The product uses a constant value, name, or reference, but this value can (or should) vary across different environments.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-330

Consequences:
  - Other: Varies by Context

Demonstrative examples:
The following code is an example of an internal hard-coded password in the back-end:
Every instance of this program can be placed into diagnostic mode with the same password. Even worse is the fact that if this program is distributed as a binary-only distribution, it is very difficult to change that password or disable this "functionality."
int VerifyAdmin(char *password) { 
                         if (strcmp(password, "Mew!")) { 
                               
                                 printf("Incorrect Password!\n"); return(0) 
                            } printf("Entering Diagnostic Mode...\n"); return(1); 
                      }
int VerifyAdmin(String password) { if (!password.equals("Mew!")) { return(0) } //Diagnostic Mode return(1); }

This code assumes a particular function will always be found at a particular address. It assigns a pointer to that address and calls the function.
The same function may not always be found at the same memory address. This could lead to a crash, or an attacker may alter the memory at the expected address, leading to arbitrary code execution.
int (*pt2Function) (float, char, char)=0x08040000; int result2 = (*pt2Function) (12, 'a', 'b'); 
                      // Here we can inject code to execute.

Real-world examples:
  - CVE-2002-0980: Component for web browser writes an error message to a known location, which can then be referenced by attackers to process HTML/script in a less restrictive context
CWE-345: Insufficient Verification of Data Authenticity

Description:
The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.

Affected languages: Not Language-Specific
Affected technologies: ICS/OT
Parent weaknesses: CWE-693

Consequences:
  - Integrity: Varies by Context

Detection methods:
  - Automated Static Analysis: Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without havin

Demonstrative examples:
In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications.
Multiple vendors did not sign firmware images.

Real-world examples:
  - CVE-2022-30260: Distributed Control System (DCS) does not sign firmware images and only relies on insecure checksums for integrity checks
  - CVE-2022-30267: Distributed Control System (DCS) does not sign firmware images and only relies on insecure checksums for integrity checks
  - CVE-2022-30272: Remote Terminal Unit (RTU) does not use signatures for firmware images and relies on insecure checksums