deardaniel/secdata-raw huggingface dataset:
CWE-1258: Exposure of Sensitive System Information Due to Uncleared Debug Information

Description:
The hardware does not fully clear security-sensitive values, such as keys and intermediate values in cryptographic operations, when debug mode is entered.

Extended Description:
Security sensitive values, keys, intermediate steps of cryptographic operations, etc. are stored in temporary registers in the hardware. If these values are not cleared when debug mode is entered they may be accessed by a debugger allowing sensitive information to be accessible by untrusted parties.

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

Consequences:
  - Confidentiality: Read Memory
  - Access Control: Bypass Protection Mechanism

Mitigations:
  - [Architecture and Design] Whenever debug mode is enabled, all registers containing sensitive assets must be cleared.

Demonstrative examples:
A cryptographic core in a System-On-a-Chip (SoC) is used for cryptographic acceleration and implements several cryptographic operations (e.g., computation of AES encryption and decryption, SHA-256, HMAC, etc.). The keys for these operations or the intermediate values are stored in registers internal to the cryptographic core. These internal registers are in the Memory Mapped Input Output (MMIO) space and are blocked from access by software and other untrusted agents on the SoC. These registers are accessible through the debug and test interface.

In the above scenario, registers that store keys and intermediate values of cryptographic operations are not cleared when system enters debug mode. An untrusted actor running a debugger may read the contents of these registers and gain access to s

The following code example is extracted from the AES wrapper module, aes1_wrapper, of the Hack@DAC'21 buggy OpenPiton System-on-Chip (SoC). Within this wrapper module are four memory-mapped registers: core_key, core_key0, core_key1, and core_key2. Core_key0, core_key1, and core_key2 hold encryption/decryption keys. The core_key register selects a key and sends it to the underlying AES module to execute encryption/decryption operations. 
                   Debug mode in processors and SoCs facilitates design debugging by granting access to internal signal/register values, including physical pin values of peripherals/core, fabric bus data transactions, and inter-peripheral registers. Debug mode allows users to gather detailed, low-level information about the design to diagnose potential issu

Real-world examples:
  - CVE-2021-33080: Uncleared debug information in memory accelerator for SSD product exposes sensitive system information
  - CVE-2022-31162: Rust library leaks Oauth client details in application debug logs
CWE-1259: Improper Restriction of Security Token Assignment

Description:
The System-On-A-Chip (SoC) implements a Security Token mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Tokens are improperly protected.

Extended Description:
Systems-On-A-Chip (Integrated circuits and hardware engines) implement Security Tokens to differentiate and identify which actions originated from which agent. These actions may be one of the directives: 'read', 'write', 'program', 'reset', 'fetch', 'compute', etc. Security Tokens are assigned to every agent in the System that is capable of generating an action or receiving an action from another agent. Multiple Security Tokens may be assigned to an agent and may be unique based on the agent's trust level or allowed privileges. Since the Security Tokens are integral for the maintenance of security in an SoC, they need to be protected properly. A common weakness afflicting Security Tokens is improperly restricting the assignment to trusted components.

Affected languages: Not Language-Specific
Affected technologies: Processor Hardware, System on Chip
Parent weaknesses: CWE-284, CWE-1294

Consequences:
  - Confidentiality: Modify Files or Directories

Mitigations:
  - [Architecture and Design] Security Token assignment review checks for design inconsistency and common weaknesses. 
							 Security-Token definition and programming flow is tested in both pre-silicon and post-silicon testing.

Demonstrative examples:
For example, consider a system with a register for storing an AES key for encryption and decryption. The key is of 128 bits implemented as a set of four 32-bit registers. The key register assets have an associated control register, AES_KEY_ACCESS_POLICY, which provides the necessary access controls. This access-policy register defines which agents may engage in a transaction, and the type of transaction, with the AES-key registers. Each bit in this 32-bit register defines a security Token. There could be a maximum of 32 security Tokens that are allowed access to the AES-key registers. The number of the bit when set (i.e., "1") allows respective action from an agent whose identity matches the number of the bit and, if "0" (i.e., Clear), disallows the respective action to that corresponding
CWE-126: Buffer Over-read

Description:
The product reads from a buffer using buffer access mechanisms such as indexes or pointers that reference memory locations after the targeted buffer.

Affected languages: Memory-Unsafe, C, C++
Parent weaknesses: CWE-125, CWE-788

Consequences:
  - Confidentiality: Read Memory
  - Confidentiality: Bypass Protection Mechanism
  - Availability: DoS: Crash, Exit, or Restart

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
  - Automated Dynamic Analysis: Use tools that are integrated during
	     compilation to insert runtime error-checking mechanisms
	     related to memory safety errors, such as AddressSanitizer
	     (ASan) for C/C++ [REF-1518].

Demonstrative examples:
In the following C/C++ example the method processMessageFromSocket() will get a message from a socket, placed into a buffer, and will parse the contents of the buffer into a structure that contains the message length and the message body. A for loop is used to copy the message body into a local character string which will be passed to another method for processing.
However, the message length variable (msgLength) from the structure is used as the condition for ending the for loop without validating that msgLength accurately reflects the actual length of the message body (CWE-606). If msgLength indicates a length that is longer than the size of a message body (CWE-130), then this can result in a buffer over-read by reading past the end of the buffer (CWE-126).
int processMessageFromSocket(i

The following C/C++ example demonstrates a buffer over-read due to a missing NULL terminator. The main method of a pattern matching utility that looks for a specific pattern within a specific file uses the string strncopy() method to copy the command line user input file name and pattern to the Filename and Pattern character arrays respectively.
However, the code do not take into account that strncpy() will not add a NULL terminator when the source buffer is equal in length of longer than that provide size attribute. Therefore if a user enters a filename or pattern that are the same size as (or larger than) their respective character arrays, a NULL terminator will not be added (CWE-170) which leads to the printf() read beyond the expected end of the Filename and Pattern buffers.
int main(i

Real-world examples:
  - CVE-2022-1733: Text editor has out-of-bounds read past end of line while indenting C code
  - CVE-2014-0160: Chain: "Heartbleed" bug receives an inconsistent length parameter (CWE-130) enabling an out-of-bounds read (CWE-126), returning memory that could include private cryptographic keys and other sensitive
  - CVE-2009-2523: Chain: product does not handle when an input string is not NULL terminated, leading to buffer over-read or heap-based buffer overflow.
CWE-1261: Improper Handling of Single Event Upsets

Description:
The hardware logic does not effectively handle when single-event upsets (SEUs) occur.

Extended Description:
Technology trends such as CMOS-transistor down-sizing, use of 
            new materials, and system-on-chip architectures continue to increase the 
            sensitivity of systems to soft errors. These errors are random, and 
            their causes might be internal (e.g., interconnect coupling) or external 
            (e.g., cosmic radiation). These soft errors are not permanent in nature 
            and cause temporary bit flips known as single-event upsets (SEUs). 
            SEUs are induced errors in circuits caused when charged particles lose 
            energy by ionizing the medium through which they pass, leaving behind a 
            wake of electron-hole pairs that cause temporary failures. If these 
            failures occur in security-sensitive modules in a chip, it might 
            compromise the security guarantees of the chip. For instance, these 
            temporary failures could be bit flips that change the privilege of
	    a regular user to root.

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

Consequences:
  - Availability: DoS: Crash, Exit, or Restart

Mitigations:
  - [Architecture and Design] Implement triple-modular redundancy around security-sensitive modules.
  - [Architecture and Design] SEUs mostly affect SRAMs.  For SRAMs storing security-critical data, implement Error-Correcting-Codes (ECC) and Address Interleaving.

Demonstrative examples:
This is an example from [REF-1089].  See the reference for full details of this issue.
Parity is error detecting but not error correcting.
Due to single-event upsets, bits are flipped in memories.  As a result, memory-parity checks fail, which results in restart and a temporary denial of service of two to three minutes.
Using error-correcting codes could have avoided the restart caused by SEUs.

In 2016, a security researcher, who was also a patient using a pacemaker, was on an airplane when a bit flip occurred in the pacemaker, likely due to the higher prevalence of cosmic radiation at such heights. The pacemaker was designed to account for bit flips and went into a default safe mode, which still forced the patient to go to a hospital to get it reset. The bit flip also inadvertently enabled the researcher to access the crash file, perform reverse engineering, and detect a hard-coded key. [REF-1101]
CWE-1263: Improper Physical Access Control

Description:
The product is designed with access restricted to certain information, but it does not sufficiently protect against an unauthorized actor with physical access to these areas.

Extended Description:
Sections of a product intended to have restricted access may be inadvertently or intentionally rendered accessible when the implemented physical protections are insufficient. The specific requirements around how robust the design of the physical protection mechanism needs to be depends on the type of product being protected. Selecting the correct physical protection mechanism and properly enforcing it through implementation and manufacturing are critical to the overall physical security of the product.

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

Consequences:
  - Confidentiality: Varies by Context

Mitigations:
  - [Architecture and Design] Specific protection requirements depend strongly on contextual factors including the level of acceptable risk associated with compromise to the product's protection mechanism. Designers could incorporate anti-tampering measures that protect against or detect when the product has been tampered with.
  - [Testing] The testing phase of the lifecycle should establish a method for determining whether the protection mechanism is sufficient to prevent unauthorized access.
  - [Manufacturing] Ensure that all protection mechanisms are fully activated at the time of manufacturing and distribution.
CWE-1264: Hardware Logic with Insecure De-Synchronization between Control and Data Channels

Description:
The hardware logic for error handling and security checks can incorrectly forward data before the security check is complete.

Extended Description:
Many high-performance on-chip bus protocols and processor data-paths employ separate channels for control and data to increase parallelism and maximize throughput. Bugs in the hardware logic that handle errors and security checks can make it possible for data to be forwarded before the completion of the security checks. If the data can propagate to a location in the hardware observable to an attacker, loss of data confidentiality can occur. 'Meltdown' is a concrete example of how de-synchronization between data and permissions checking logic can violate confidentiality requirements. Data loaded from a page marked as privileged was returned to the CPU regardless of current privilege level for performance reasons. The assumption was that the CPU could later remove all traces of this data during the handling of the illegal memory access exception, but this assumption was proven false as traces of the secret data were not removed from the microarchitectural state.

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

Consequences:
  - Confidentiality: Read Memory

Mitigations:
  - [Architecture and Design] Thoroughly verify the data routing logic to ensure that any error handling or security checks effectively block illegal dataflows.

Demonstrative examples:
There are several standard on-chip bus protocols used in modern SoCs to allow communication between components. There are a wide variety of commercially available hardware IP implementing the interconnect logic for these protocols. A bus connects components which initiate/request communications such as processors and DMA controllers (bus masters) with peripherals which respond to requests. In a typical system, the privilege level or security designation of the bus master along with the intended functionality of each peripheral determine the security policy specifying which specific bus masters can access specific peripherals.  This security policy (commonly referred to as a bus firewall) can be enforced using separate IP/logic from the actual interconnect responsible for the data routing.


Real-world examples:
  - CVE-2017-5754: Systems with microprocessors utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel an
CWE-1266: Improper Scrubbing of Sensitive Data from Decommissioned Device

Description:
The product does not properly provide a capability for the product administrator to remove sensitive data at the time the product is decommissioned.  A scrubbing capability could be missing, insufficient, or incorrect.

Extended Description:
When a product is decommissioned - i.e., taken out of service - best practices or regulatory requirements may require the administrator to remove or overwrite sensitive data first, i.e. "scrubbing."  Improper scrubbing of sensitive data from a decommissioned device leaves that data vulnerable to acquisition by a malicious actor. Sensitive data may include, but is not limited to, device/manufacturer proprietary information, user/device credentials, network configurations, and other forms of sensitive data.

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

Consequences:
  - Confidentiality: Read Memory

Mitigations:
  - [Architecture and Design] Functionality to completely scrub data from a product at the conclusion of its lifecycle should be part of the design phase. Trying to add this function on top of an existing architecture could lead to incomplete removal of sensitive information/data.
  - [Policy] The manufacturer should describe the location(s) where sensitive data is stored and the policies and procedures for its removal. This information may be conveyed, for example, in an Administrators Guide or a Statement of Volatility.
  - [Implementation] If the capability to wipe sensitive data isn't built-in, the manufacturer may need to provide a utility to scrub sensitive data from storage if that data is located in a place which is non-accessible by the administrator. One example of this could be when sensitive data is stored on an EEPROM for wh
CWE-1267: Policy Uses Obsolete Encoding

Description:
The product uses an obsolete encoding mechanism to implement access controls.

Extended Description:
Within a System-On-a-Chip (SoC), various circuits and hardware engines generate transactions for the purpose of accessing (read/write) assets or performing various actions (e.g., reset, fetch, compute, etc.). Among various types of message information, a typical transaction is comprised of source identity (identifying the originator of the transaction) and a destination identity (routing the transaction to the respective entity). Sometimes the transactions are qualified with a Security Token. This Security Token helps the destination agent decide on the set of allowed actions (e.g., access to an asset for reads and writes). A policy encoder is used to map the bus transactions to Security Tokens that in turn are used as access-controls/protection mechanisms. A common weakness involves using an encoding which is no longer trusted, i.e., an obsolete encoding.

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

Consequences:
  - Confidentiality: Modify Memory

Mitigations:
  - [Architecture and Design] Security Token Decoders should be reviewed for design inconsistency and common weaknesses. 
       Access and programming flows should be tested in both pre-silicon and post-silicon testing.

Demonstrative examples:
For example, consider a system that has four bus masters. The table below provides bus masters, their Security Tokens, and trust assumptions. 
        
         
          Bus Master 
          Security Token Decoding 
          Trust Assumptions 
         
         
          Master_0 
          "00" 
          Untrusted 
         
         
          Master_1 
          "01" 
          Trusted 
         
         
          Master_2 
          "10" 
          Untrusted 
         
         
          Master_3 
          "11" 
          Untrusted 
         
        
        The policy encoding is to be defined such that Security Token will be used in implemented access-controls. The bits in the bus transaction that contain Security-Token information are Bus_transaction [15:11]. The assets
CWE-1268: Policy Privileges are not Assigned Consistently Between Control and Data Agents

Description:
The product's hardware-enforced access control for a particular resource improperly accounts for privilege discrepancies between control and write policies.

Extended Description:
Integrated circuits and hardware engines may provide access to resources (device-configuration, encryption keys, etc.) belonging to trusted firmware or software modules (commonly set by a BIOS or a bootloader). These accesses are typically controlled and limited by the hardware. Hardware design access control is sometimes implemented using a policy. A policy defines which entity or agent may or may not be allowed to perform an action. When a system implements multiple levels of policies, a control policy may allow direct access to a resource as well as changes to the policies themselves. 
				 Resources that include agents in their control policy but not in their write policy could unintentionally allow an untrusted agent to insert itself in the write policy register. Inclusion in the write policy register could allow a malicious or misbehaving agent write access to resources. This action could result in security compromises including leaked information, leaked encryption keys, or modi

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

Consequences:
  - Confidentiality: Modify Memory

Mitigations:
  - [Architecture and Design] Access-control-policy definition and programming flow must be sufficiently tested in pre-silicon and post-silicon testing.

Demonstrative examples:
Consider a system of seven registers for storing and configuring an AES key for encryption or decryption. 
					 Four 32-bit registers are used to store a 128-bit AES key. The names of those registers are AES_ENC_DEC_KEY_0, AES_ENC_DEC_KEY_1, AES_ENC_DEC_KEY_2, and AES_ENC_DEC_KEY_3. Collectively these are referred to as the AES Key registers. 
					 
						 Register Field description 
						 AES_ENC_DEC_KEY_0 AES key [0:31] for encryption or decryption Default 0x00000000 
						 AES_ENC_DEC_KEY_1 AES key [32:63] for encryption or decryption Default 0x00000000 
						 AES_ENC_DEC_KEY_2 AES key [64:95] for encryption or decryption Default 0x00000000 
						 AES_ENC_DEC_KEY_3 AES key [96:127] for encryption or decryption Default 0x00000000 
					 
					 Three 32-bit registers are used to def
CWE-127: Buffer Under-read

Description:
The product reads from a buffer using buffer access mechanisms such as indexes or pointers that reference memory locations prior to the targeted buffer.

Affected languages: Memory-Unsafe, C, C++
Parent weaknesses: CWE-125, CWE-786

Consequences:
  - Confidentiality: Read Memory
  - Confidentiality: 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
  - Automated Dynamic Analysis: Use tools that are integrated during
	     compilation to insert runtime error-checking mechanisms
	     related to memory safety errors, such as AddressSanitizer
	     (ASan) for C/C++ [REF-1518].

Demonstrative examples:
In the following code, the method retrieves a value from an array at a specific array index location that is given as an input parameter to the method
However, this method only verifies that the given array index is less than the maximum length of the array but does not check for the minimum value (CWE-839). This will allow a negative value to be accepted as the input array index, which will result in reading data before the beginning of the buffer (CWE-127) and may allow access to sensitive memory. The input array index should be checked to verify that is within the maximum and minimum range required for the array (CWE-129). In this example the if statement should be modified to include a minimum range check, as shown below.
int getValueFromArray(int *array, int len, int index) { 
       

Real-world examples:
  - CVE-2021-40985: HTML conversion package has a buffer under-read, allowing a crash