deardaniel/secdata-raw huggingface dataset:
CWE-128: Wrap-around Error

Description:
Wrap around errors occur whenever a value is incremented past the maximum value for its type and therefore "wraps around" to a very small, negative, or undefined value.

Affected languages: C, C++
Parent weaknesses: CWE-682

Consequences:
  - Availability: DoS: Crash, Exit, or Restart
  - Integrity: Modify Memory
  - Confidentiality: Execute Unauthorized Code or Commands

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:
  - Requirements specification: The choice could be made to use a language that is not susceptible to these issues.
  - [Architecture and Design] Provide clear upper and lower bounds on the scale of any protocols designed.
  - [Implementation] Perform validation on all incremented variables to ensure that they remain within reasonable bounds.

Demonstrative examples:
The following image processing code allocates a table for images.
This code intends to allocate a table of size num_imgs, however as num_imgs grows large, the calculation determining the size of the list will eventually overflow (CWE-190). This will result in a very small list to be allocated instead. If the subsequent code operates on the list as if it were num_imgs long, it may result in many types of out-of-bounds problems (CWE-119).
img_t table_ptr; /*struct containing img data, 10kB each*/ int num_imgs; ... num_imgs = get_num_imgs(); table_ptr = (img_t*)malloc(sizeof(img_t)*num_imgs); ...
CWE-1280: Access Control Check Implemented After Asset is Accessed

Description:
A product's hardware-based access control check occurs after the asset has been accessed.

Extended Description:
The product implements a hardware-based access control check. The asset should be accessible only after the check is successful. If, however, this operation is not atomic and the asset is accessed before the check is complete, the security of the system may be compromised.

Affected languages: Verilog, VHDL, Not Language-Specific
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-696, CWE-284

Consequences:
  - Access Control: Modify Memory

Mitigations:
  - [Implementation] Implement the access control check first. Access should only be given to asset if agent is authorized.

Demonstrative examples:
Assume that the module foo_bar implements a protected register. The register content is the asset. Only transactions made by user id (indicated by signal usr_id) 0x4 are allowed to modify the register contents. The signal grant_access is used to provide access.
This code uses Verilog blocking assignments for data_out and grant_access. Therefore, these assignments happen sequentially (i.e., data_out is updated to new value first, and grant_access is updated the next cycle) and not in parallel. Therefore, the asset data_out is allowed to be modified even before the access control check is complete and grant_access signal is set. Since grant_access does not have a reset value, it will be meta-stable and will randomly go to either 0 or 1.
module foo_bar(data_out, usr_id, data_in, clk, rst_n);
CWE-1281: Sequence of Processor Instructions Leads to Unexpected Behavior

Description:
Specific combinations of processor instructions lead to undesirable behavior such as locking the processor until a hard reset performed.

Extended Description:
If the instruction set architecture (ISA) and processor logic are not designed carefully and tested thoroughly, certain combinations of instructions may lead to locking the processor or other unexpected and undesirable behavior.  Upon encountering unimplemented instruction opcodes or illegal instruction operands, the processor should throw an exception and carry on without negatively impacting security.  However, specific combinations of legal and illegal instructions may cause unexpected behavior with security implications such as allowing unprivileged programs to completely lock the CPU.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific, Processor Hardware
Parent weaknesses: CWE-691

Consequences:
  - Integrity: Varies by Context

Mitigations:
  - [Testing] Implement a rigorous testing strategy that incorporates randomization to explore instruction sequences that are unlikely to appear in normal workloads in order to identify halt and catch fire instruction sequences.
  - [Patching and Maintenance] Patch operating system to avoid running Halt and Catch Fire type sequences or to mitigate the damage caused by unexpected behavior.  See [REF-1108].

Demonstrative examples:
The Pentium F00F bug is a real-world example of how a sequence of instructions can lock a processor. The "cmpxchg8b" instruction compares contents of registers with a memory location.  The operand is expected to be a memory location, but in the bad code snippet it is the eax register. Because the specified operand is illegal, an exception is generated, which is the correct behavior and not a security issue in itself. However, when prefixed with the "lock" instruction, the processor deadlocks because locked memory transactions require a read and write pair of transactions to occur before the lock on the memory bus is released. The exception causes a read to occur but there is no corresponding write, as there would have been if a legal operand had been supplied to the cmpxchg8b instruction. 

The Cyrix Coma bug was capable of trapping a Cyrix 6x86, 6x86L, or 6x86MX processor in an infinite loop. An infinite loop on a processor is not necessarily an issue on its own, as interrupts could stop the loop. However, on select Cyrix processors, the x86 Assembly 'xchg' instruction was designed to prevent interrupts. On these processors, if the loop was such that a new 'xchg' instruction entered the instruction pipeline before the previous one exited, the processor would become deadlocked. [REF-1323]

Real-world examples:
  - CVE-2021-26339: A bug in AMD CPU's core logic allows a potential DoS by using a specific x86 instruction sequence to hang the processor
  - CVE-1999-1476: A bug in some Intel Pentium processors allow DoS (hang) via an invalid "CMPXCHG8B" instruction, causing a deadlock
CWE-1282: Assumed-Immutable Data is Stored in Writable Memory

Description:
Immutable data, such as a first-stage bootloader, device identifiers, and "write-once" configuration settings are stored in writable memory that can be re-programmed or updated in the field.

Extended Description:
Security services such as secure boot, authentication of code and data, and device attestation all require assets such as the first stage bootloader, public keys, golden hash digests, etc. which are implicitly trusted. Storing these assets in read-only memory (ROM), fuses, or one-time programmable (OTP) memory provides strong integrity guarantees and provides a root of trust for securing the rest of the system. Security is lost if assets assumed to be immutable can be modified.

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

Consequences:
  - Integrity: Varies by Context

Mitigations:
  - [Implementation] All immutable code or data should be programmed into ROM or write-once memory.

Demonstrative examples:
Cryptographic hash functions are commonly used to create unique fixed-length digests used to ensure the integrity of code and keys. A golden digest is stored on the device and compared to the digest computed from the data to be verified. If the digests match, the data has not been maliciously modified. If an attacker can modify the golden digest they then have the ability to store arbitrary data that passes the verification check. Hash digests used to verify public keys and early stage boot code should be immutable, with the strongest protection offered by hardware immutability.
CWE-1283: Mutable Attestation or Measurement Reporting Data

Description:
The register contents used for attestation or measurement reporting data to verify boot flow are modifiable by an adversary.

Extended Description:
A System-on-Chip (SoC) implements secure boot or verified boot. During this boot flow, the SoC often measures the code that it authenticates. The measurement is usually done by calculating the one-way hash of the code binary and extending it to the previous hash. The hashing algorithm should be a Secure One-Way hash function. The final hash, i.e., the value obtained after the completion of the boot flow, serves as the measurement data used in reporting or in attestation. The calculated hash is often stored in registers that can later be read by the party of interest to determine tampering of the boot flow. A common weakness is that the contents in these registers are modifiable by an adversary, thus spoofing the measurement.

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

Consequences:
  - Confidentiality: Read Memory

Mitigations:
  - [Architecture and Design] Measurement data should be stored in registers that are read-only or otherwise have access controls that prevent modification by an untrusted agent.

Demonstrative examples:
The SoC extends the hash and stores the results in registers. Without protection, an adversary can write their chosen hash values to these registers. Thus, the attacker controls the reported results.
To prevent the above scenario, the registers should have one or more of the following properties: 
                     
                         Should be Read-Only with respect to an adversary 
                         Cannot be extended or modifiable either directly or indirectly (using a trusted agent as proxy) by an adversary 
                         Should have appropriate access controls or protections
CWE-1286: Improper Validation of Syntactic Correctness of Input

Description:
The product receives input that is expected to be well-formed - i.e., to comply with a certain syntax - but it does not validate or incorrectly validates that the input complies with the syntax.

Extended Description:
Often, complex inputs are expected to follow a particular syntax, which is either assumed by the input itself, or declared within metadata such as headers. The syntax could be for data exchange formats, markup languages, or even programming languages.  When untrusted input is not properly validated for the expected syntax, attackers could cause parsing failures, trigger unexpected errors, or expose latent vulnerabilities that might not be directly exploitable if the input had conformed to the syntax.

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

Consequences:
  - Other: Varies by Context

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

Demonstrative examples:
The following code loads and parses an XML file.
The XML file is loaded without validating it against a known XML Schema or DTD.
// Read DOM 
                      try { ... DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); factory.setValidating( false ); .... c_dom = factory.newDocumentBuilder().parse( xmlFile ); } catch(Exception ex) { ... }

Real-world examples:
  - CVE-2016-4029: Chain: incorrect validation of intended decimal-based IP address format (CWE-1286) enables parsing of octal or hexadecimal formats (CWE-1389), allowing bypass of an SSRF protection mechanism (CWE-918)
  - CVE-2007-5893: HTTP request with missing protocol version number leads to crash
CWE-1287: Improper Validation of Specified Type of Input

Description:
The product receives input that is expected to be of a certain type, but it does not validate or incorrectly validates that the input is actually of the expected type.

Extended Description:
When input does not comply with the expected type, attackers could trigger unexpected errors, cause incorrect actions to take place, or exploit latent vulnerabilities that would not be possible if the input conformed with the expected type. 
				 This weakness can appear in type-unsafe programming languages, or in programming languages that support casting or conversion of an input to another type.

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

Consequences:
  - Other: Varies by Context

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

Real-world examples:
  - CVE-2024-37032: Large language model (LLM) management tool does not
               validate the format of a digest value (CWE-1287) from a
               private, untrusted model registry, enabling relative
         
  - CVE-2008-2223: SQL injection through an ID that was supposed to be numeric.
CWE-1288: Improper Validation of Consistency within Input

Description:
The product receives a complex input with multiple elements or fields that must be consistent with each other, but it does not validate or incorrectly validates that the input is actually consistent.

Extended Description:
Some input data can be structured with multiple elements or fields that must be consistent with each other, e.g. a number-of-items field that is followed by the expected number of elements.  When such complex inputs are inconsistent, attackers could trigger unexpected errors, cause incorrect actions to take place, or exploit latent vulnerabilities.

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

Consequences:
  - Other: Varies by Context

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

Real-world examples:
  - CVE-2018-16733: product does not validate that the start block appears before the end block
  - CVE-2006-3790: size field that is inconsistent with packet size leads to buffer over-read
  - CVE-2008-4114: system crash with offset value that is inconsistent with packet size
CWE-1289: Improper Validation of Unsafe Equivalence in Input

Description:
The product receives an input value that is used as a resource identifier or other type of reference, but it does not validate or incorrectly validates that the input is equivalent to a potentially-unsafe value.

Extended Description:
Attackers can sometimes bypass input validation schemes by finding inputs that appear to be safe, but will be dangerous when processed at a lower layer or by a downstream component.  For example, a simple XSS protection mechanism might try to validate that an input has no "<script>" tags using case-sensitive matching, but since HTML is case-insensitive when processed by web browsers, an attacker could inject "<ScrIpT>" and trigger XSS.

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

Consequences:
  - Other: Varies by Context

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

Real-world examples:
  - CVE-2021-39155: Chain: A microservice integration and management platform compares the hostname in the HTTP Host header in a case-sensitive way (CWE-178, CWE-1289), allowing bypass of the authorization policy (CWE-86
  - CVE-2020-11053: Chain: Go-based Oauth2 reverse proxy can send the authenticated user to another site at the end of the authentication flow. A redirect URL with HTML-encoded whitespace characters can bypass the valida
  - CVE-2005-0269: File extension check in forum software only verifies extensions that contain all lowercase letters, which allows remote attackers to upload arbitrary files via file extensions that include uppercase l
  - CVE-2001-1238: Task Manager does not allow local users to end processes with uppercase letters named (1) winlogon.exe, (2) csrss.exe, (3) smss.exe and (4) services.exe via the Process tab which could allow local use
  - CVE-2004-2214: HTTP server allows bypass of access restrictions using URIs with mixed case.
CWE-1290: Incorrect Decoding of Security Identifiers

Description:
The product implements a decoding mechanism to decode certain bus-transaction signals to security identifiers. If the decoding is implemented incorrectly, then untrusted agents can now gain unauthorized access to the asset.

Extended Description:
In a System-On-Chip (SoC), various integrated circuits and hardware engines generate transactions such as to access (reads/writes) assets or perform certain actions (e.g., reset, fetch, compute, etc.). Among various types of message information, a typical transaction is comprised of source identity (to identify the originator of the transaction) and a destination identity (to route the transaction to the respective entity). Sometimes the transactions are qualified with a security identifier. The security identifier helps the destination agent decide on the set of allowed actions (e.g., access an asset for read and writes). A decoder decodes the bus transactions to map security identifiers into necessary access-controls/protections. 
				 A common weakness that can exist in this scenario is incorrect decoding because an untrusted agent's security identifier is decoded into a trusted agent's security identifier. Thus, an untrusted agent previously without access to an asset can now gain 

Affected languages: Not Language-Specific
Affected technologies: Bus/Interface Hardware, Not Technology-Specific
Parent weaknesses: CWE-284, CWE-1294

Consequences:
  - Confidentiality: Modify Memory

Mitigations:
  - [Architecture and Design] Security identifier decoders must be reviewed for design consistency and common weaknesses.
  - [Implementation] Access and programming flows must be tested in pre-silicon and post-silicon testing in order to check for this weakness.

Demonstrative examples:
Consider a system that has four bus masters and a decoder. The decoder is supposed to decode every bus transaction and assign a corresponding security identifier. The security identifier is used to determine accesses to the assets. The bus transaction that contains the security information is Bus_transaction [15:14], and the bits 15 through 14 contain the security identifier information. The table below provides bus masters as well as their security identifiers and trust assumptions:
                         
                         
                             Bus Master Security Identifier Decoding Trust Assumptions 
                             Master_0 "00" Untrusted 
                             Master_1 "01" Trusted 
                             Master_2 "10" Untrusted
CWE-1291: Public Key Re-Use for Signing both Debug and Production Code

Description:
The same public key is used for signing both debug and production code.

Extended Description:
A common usage of public-key cryptography is to verify the integrity and authenticity of another entity (for example a firmware binary). If a company wants to ensure that its firmware runs only on its own hardware, before the firmware runs, an encrypted hash of the firmware image will be decrypted with the public key and then verified against the now-computed hash of the firmware image. This means that the public key forms the root of trust, which necessitates that the public key itself must be protected and used properly. 
				 During the development phase, debug firmware enables many hardware debug hooks, debug modes, and debug messages for testing. Those debug facilities provide significant, additional views about the firmware's capability and, in some cases, additional capability into the chip or SoC. If compromised, these capabilities could be exploited by an attacker to take full control of the system. 
				 Once the product exits the manufacturing stage and enters production, it

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

Consequences:
  - Confidentiality: Read Memory

Detection methods:
  - Architecture or Design Review: Compare the debug key with the production key to make sure that they are not the same.
  - Dynamic Analysis with Manual Results Interpretation: Compare the debug key with the production key to make sure that they are not the same.

Mitigations:
  - [Implementation] Use different keys for Production and Debug.

Demonstrative examples:
This example illustrates the danger of using the same public key for debug and production.

Suppose the product design requires frugality of silicon real estate. Assume that originally the architecture allows just enough storage for two 2048-bit RSA keys in the fuse: one to be used for debug and the other for production. However, in the meantime, a business decision is taken to make the security future-proof beyond 2030, which means the architecture needs to use the NIST-recommended 3072-bit keys instead of the originally-planned 2048-bit keys. This means that, at most, one key can be fully stored in the fuses, not two. So the product design team decides to use the same public key for debug and production.
Increase the storage so that two different keys of the required size can be stored.