deardaniel/secdata-raw huggingface dataset:
CWE-1243: Sensitive Non-Volatile Information Not Protected During Debug

Description:
Access to security-sensitive information stored in fuses is not limited during debug.

Extended Description:
Several security-sensitive values are programmed into fuses to be used during early-boot flows or later at runtime. Examples of these security-sensitive values include root keys, encryption keys, manufacturing-specific information, chip-manufacturer-specific information, and original-equipment-manufacturer (OEM) data. After the chip is powered on, these values are sensed from fuses and stored in temporary locations such as registers and local memories. These locations are typically access-control protected from untrusted agents capable of accessing them. Even to trusted agents, only read-access is provided.

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

Consequences:
  - Confidentiality: Modify Memory

Mitigations:
  - [Architecture and Design] Disable access to security-sensitive information stored in fuses directly and also reflected from temporary storage locations when in debug mode.

Demonstrative examples:
Sensitive manufacturing data (such as die information) are stored in fuses. When the chip powers on, these values are read from the fuses and stored in microarchitectural registers. These registers are only given read access to trusted software running on the core. Untrusted software running on the core is not allowed to access these registers.

All microarchitectural registers in this chip can be accessed through the debug interface. As a result, even an untrusted debugger can access this data and retrieve sensitive manufacturing data.
Registers used to store sensitive values read from fuses should be blocked during debug. These registers should be disconnected from the debug interface.

The example code below is taken from one of the AES cryptographic accelerators of the HACK@DAC'21 buggy OpenPiton SoC [REF-1366]. The operating system (OS) uses three AES keys to encrypt and decrypt sensitive data using this accelerator. These keys are sensitive data stored in fuses. The security of the OS will be compromised if any of these AES keys are leaked. During system bootup, these AES keys are sensed from fuses and stored in temporary hardware registers of the AES peripheral. Access to these temporary registers is disconnected during the debug state to prevent them from leaking through debug access. In this example (see the vulnerable code source), the registers key0, key1, and key2 are used to store the three AES keys (which are accessed through key_big0, key_big1, and key_big2 s
CWE-1245: Improper Finite State Machines (FSMs) in Hardware Logic

Description:
Faulty finite state machines (FSMs) in the hardware logic allow an attacker to put the system in an undefined state, to cause a denial of service (DoS) or gain privileges on the victim's system.

Extended Description:
The functionality and security of the system heavily depend on the implementation of FSMs. FSMs can be used to indicate the current security state of the system. Lots of secure data operations and data transfers rely on the state reported by the FSM.

Affected languages: Not Language-Specific
Affected technologies: System on Chip
Parent weaknesses: CWE-684

Consequences:
  - Availability: Unexpected State

Mitigations:
  - [Architecture and Design] Define all possible states and handle all unused states through default statements. Ensure that system defaults to a secure state.

Demonstrative examples:
The Finite State Machine (FSM) shown in the "bad" code snippet below assigns the output ("out") based on the value of state, which is determined based on the user provided input ("user_input").
The case statement does not include a default to handle the scenario when the user provides inputs of 3'h6 and 3'h7.  Those inputs push the system to an undefined state and might cause a crash (denial of service) or any other unanticipated outcome. 
					   Adding a default statement to handle undefined inputs mitigates this issue.  This is shown in the "Good" code snippet below.  The default statement is in bold.
module fsm_1(out, user_input, clk, rst_n);
					   input [2:0] user_input; 
					   input clk, rst_n;
					   output reg [2:0] out;
					   reg [1:0] state;
					   always @ (posedge clk o
CWE-1246: Improper Write Handling in Limited-write Non-Volatile Memories

Description:
The product does not implement or incorrectly implements wear leveling operations in limited-write non-volatile memories.

Extended Description:
Non-volatile memories such as NAND Flash, EEPROM, etc. have individually erasable segments, each of which can be put through a limited number of program/erase or write cycles. For example, the device can only endure a limited number of writes, after which the device becomes unreliable. In order to wear out the cells in a uniform manner, non-volatile memory and storage products based on the above-mentioned technologies implement a technique called wear leveling. Once a set threshold is reached, wear leveling maps writes of a logical block to a different physical block. This prevents a single physical block from prematurely failing due to a high concentration of writes.

Affected languages: Not Language-Specific
Affected technologies: System on Chip, Memory Hardware, Storage Hardware
Parent weaknesses: CWE-400

Consequences:
  - Availability: DoS: Instability

Mitigations:
  - [Architecture and Design] Include secure wear leveling algorithms and ensure they may not be bypassed.

Demonstrative examples:
An attacker can render a memory line unusable by repeatedly causing a write to the memory line.
Below is example code from [REF-1058] that the user can execute repeatedly to cause line failure. W is the maximum associativity of any cache in the system; S is the size of the largest cache in the system.
// Do aligned alloc of (W+1) arrays each of size S 
					while(1) { 
					 
					  for (ii = 0; ii < W + 1; ii++) 
					   
					    array[ii].element[0]++; 
					   
					 
					}
Wear leveling must be used to even out writes to the device.
CWE-1248: Semiconductor Defects in Hardware Logic with Security-Sensitive Implications

Description:
The security-sensitive hardware module contains semiconductor defects.

Extended Description:
A semiconductor device can fail for various reasons. While some are manufacturing and packaging defects, the rest are due to prolonged use or usage under extreme conditions. Some mechanisms that lead to semiconductor defects include encapsulation failure, die-attach failure, wire-bond failure, bulk-silicon defects, oxide-layer faults, aluminum-metal faults (including electromigration, corrosion of aluminum, etc.), and thermal/electrical stress. These defects manifest as faults on chip-internal signals or registers, have the effect of inputs, outputs, or intermediate signals being always 0 or always 1, and do not switch as expected.

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

Consequences:
  - Availability: DoS: Instability

Mitigations:
  - [Testing] While semiconductor-manufacturing companies implement several mechanisms to continuously improve the semiconductor manufacturing process to ensure reduction of defects, some defects can only be fixed after manufacturing. Post-manufacturing testing of silicon die is critical. Fault models such as stu
  - [Operation] Operating the hardware outside device specification, such as at extremely high temperatures, voltage, etc., accelerates semiconductor degradation and results in defects.  When these defects manifest as faults in security-critical, hardware modules, it results in compromise of security guarantees. Th

Demonstrative examples:
The network-on-chip implements a firewall for access control to peripherals from all IP cores capable of mastering transactions.
Post-manufacture testing must be performed to ensure that hardware logic implementing security functionalities is defect-free.
A manufacturing defect in this logic manifests itself as a logical fault, which always sets the output of the filter to "allow" access.
CWE-1249: Application-Level Admin Tool with Inconsistent View of Underlying Operating System

Description:
The product provides an application for administrators to manage parts of the underlying operating system, but the application does not accurately identify all of the relevant entities or resources that exist in the OS; that is, the application's model of the OS's state is inconsistent with the OS's actual state.

Extended Description:
Many products provide web-based applications or other interfaces for managing the underlying operating system. This is common with cloud, network access devices, home networking, and other systems.  When the management tool does not accurately represent what is in the OS - such as user accounts - then the administrator might not see suspicious activities that would be noticed otherwise. 
				 For example, numerous systems utilize a web
				front-end for administrative control. They also offer
				the ability to add, alter, and drop users with various
				privileges as it relates to the functionality of the
				system.  A potential architectural weakness may exist
				where the user information reflected in the web
				interface does not mirror the users in the underlying
				operating system.  Many web UI or REST APIs use the
				underlying operating system for authentication; the
				system's logic may also track an additional set of
				user capabilities within configuration files
		

Affected languages: Not Language-Specific
Affected technologies: Web Based
Parent weaknesses: CWE-1250

Consequences:
  - Access Control: Varies by Context
  - Accountability: Hide Activities
  - Other: Unexpected State

Mitigations:
  - [Architecture and Design] Ensure that the admin tool refreshes its model of the underlying OS on a regular basis, and note any inconsistencies with configuration files or other data sources that are expected to have the same data.

Demonstrative examples:
Suppose that an attacker successfully gains root privileges on a Linux system and adds a new 'user2' account:
This new user2 account would not be noticed on the web interface, if the interface does not refresh its data of available users.
echo "user2:x:0:0::/root:/" >> /etc/passwd; 
					   echo
					  "user2:\$6\$IdvyrM6VJnG8Su5U\$1gmW3Nm.IO4vxTQDQ1C8urm72JCadOHZQwqiH/nRtL8dPY80xS4Ovsv5bPCMWnXKKWwmsocSWXupUf17LB3oS.:17256:0:99999:7:::" >> /etc/shadow;
CWE-1250: Improper Preservation of Consistency Between Independent Representations of Shared State

Description:
The product has or supports multiple distributed components or sub-systems that are each required to keep their own local copy of shared data - such as state or cache - but the product does not ensure that all local copies remain consistent with each other.

Extended Description:
In highly distributed environments, or on systems with distinct physical components that operate independently, there is often a need for each component to store and update its own local copy of key data such as state or cache, so that all components have the same "view" of the overall system and operate in a coordinated fashion.  For example, users of a social media service or a massively multiplayer online game might be using their own personal computers while also interacting with different physical hosts in a globally distributed service, but all participants must be able to have the same "view" of the world.  Alternately, a processor's Memory Management Unit (MMU) might have "shadow" MMUs to distribute its workload, and all shadow MMUs are expected to have the same accessible ranges of memory. 
		 In such environments, it becomes critical for
		the product to ensure that this "shared state" is
		consistently modified across all distributed systems.
		If state is not consistently m

Affected languages: Not Language-Specific
Affected technologies: Cloud Computing, Security Hardware
Parent weaknesses: CWE-664

Consequences:
  - Other: Unexpected State

Demonstrative examples:
Suppose a processor's Memory Management Unit (MMU) has 5 other shadow MMUs to distribute its workload for its various cores. Each MMU has the start address and end address of "accessible" memory. Any time this accessible range changes (as per the processor's boot status), the main MMU sends an update message to all the shadow MMUs.
Suppose the interconnect fabric does not prioritize such "update" packets over other general traffic packets. This introduces a race condition. If an attacker can flood the target with enough messages so that some of those attack packets reach the target before the new access ranges gets updated, then the attacker can leverage this scenario.
CWE-1251: Mirrored Regions with Different Values

Description:
The product's architecture mirrors regions without ensuring that their contents always stay in sync.

Extended Description:
Having mirrored regions with different values might result in the exposure of sensitive information or possibly system compromise. 
				 In the interest of increased performance, one might need to duplicate a resource. A cache memory is a common example of this concept, which keeps a "local" copy of a data element in the high speed cache memory. Unfortunately, this speed improvement comes with a downside, since the product needs to ensure that the local copy always mirrors the original copy truthfully. If they get out of sync, the computational result is no longer true. 
				 During hardware design, memory is not the only item which gets mirrored. There are many other entities that get mirrored, as well: registers, memory regions, and, in some cases, even whole computational units. For example, within a multi-core processor, if all memory accesses for each and every core goes through a single Memory-Management Unit (MMU) then the MMU will become a performance bottleneck. In such cases,

Affected languages: VHDL, Verilog
Affected technologies: System on Chip
Parent weaknesses: CWE-1250

Consequences:
  - Confidentiality: Varies by Context

Mitigations:
  - [Architecture and Design] Whenever there are multiple, physically different copies of the same value that might change and the process to update them is not instantaneous and atomic, it is impossible to assert that the original and shadow copies will always be in sync - there will always be a time period when they are out of

Demonstrative examples:
Suppose a processor's Memory Management Unit (MMU) has 5 other shadow MMUs to distribute its workload for its various cores. Each MMU has the start address and end address of "accessible" memory. Any time this accessible range changes (as per the processor's boot status), the main MMU sends an update message to all the shadow MMUs.
Suppose the interconnect fabric does not prioritize such "update" packets over other general traffic packets. This introduces a race condition. If an attacker can flood the target with enough messages so that some of those attack packets reach the target before the new access ranges gets updated, then the attacker can leverage this scenario.
CWE-1252: CPU Hardware Not Configured to Support Exclusivity of Write and Execute Operations

Description:
The CPU is not configured to provide hardware support for exclusivity of write and execute operations on memory. This allows an attacker to execute data from all of memory.

Extended Description:
CPUs provide a special bit that supports exclusivity of write and execute operations. This bit is used to segregate areas of memory to either mark them as code (instructions, which can be executed) or data (which should not be executed). In this way, if a user can write to a region of memory, the user cannot execute from that region and vice versa. This exclusivity provided by special hardware bit is leveraged by the operating system to protect executable space. While this bit is available in most modern processors by default, in some CPUs the exclusivity is implemented via a memory-protection unit (MPU) and memory-management unit (MMU) in which memory regions can be carved out with exact read, write, and execute permissions. However, if the CPU does not have an MMU/MPU, then there is no write exclusivity.

Affected languages: Not Language-Specific
Affected technologies: Microcontroller Hardware, Processor Hardware
Parent weaknesses: CWE-284

Consequences:
  - Confidentiality: Execute Unauthorized Code or Commands

Mitigations:
  - [Architecture and Design] Implement a dedicated bit that can be leveraged by the Operating System to mark data areas as non-executable. If such a bit is not available in the CPU, implement MMU/MPU (memory management unit / memory protection unit).
  - [Integration] If MMU/MPU are not available, then the firewalls need to be implemented in the SoC interconnect to mimic the write-exclusivity operation.

Demonstrative examples:
MCS51 Microcontroller (based on 8051) does not have a special bit to support write exclusivity. It also does not have an MMU/MPU support. The Cortex-M CPU has an optional MPU that supports up to 8 regions.
If the MPU is not configured, then an attacker will be able to inject malicious data into memory and execute it.
The optional MPU is not configured.
CWE-1253: Incorrect Selection of Fuse Values

Description:
The logic level used to set a system to a secure state relies on a fuse being unblown.

Extended Description:
Fuses are often used to store secret data, including security configuration data. When not blown, a fuse is considered to store a logic 0, and, when blown, it indicates a logic 1. Fuses are generally considered to be one-directional, i.e., once blown to logic 1, it cannot be reset to logic 0.

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

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

Mitigations:
  - [Architecture and Design] Logic should be designed in a way that blown fuses do not put the product into an insecure state that can be leveraged by an attacker.

Demonstrative examples:
A chip implements a secure boot and uses the sensed value of a fuse 
         "do_secure_boot" to determine whether to perform a secure boot or not. If this fuse 
         value is "0", the system performs secure boot. Otherwise, it does not perform secure 
         boot. 
          An attacker blows the "do_secure_boot" fuse to "1". After reset, the attacker loads a custom 
         bootloader, and, since the fuse value is now "1", the system does not perform secure boot, 
         and the attacker can execute their custom firmware image. 
          Since by default, a fuse-configuration value is a "0", an attacker can blow it to a "1" with 
         inexpensive hardware. 
          If the logic is reversed, an attacker cannot easily reset the fuse. Note that, with 
         specialized a
CWE-1254: Incorrect Comparison Logic Granularity

Description:
The product's comparison logic is performed over a series of steps rather than across the entire string in one operation. If there is a comparison logic failure on one of these steps, the operation may be vulnerable to a timing attack that can result in the interception of the process for nefarious purposes.

Extended Description:
Comparison logic is used to compare a variety of objects including passwords, Message 
         Authentication Codes (MACs), and responses to verification challenges. When comparison logic is 
         implemented at a finer granularity (e.g., byte-by-byte comparison) and breaks in the case of a 
         comparison failure, an attacker can exploit this implementation to identify when exactly 
         the failure occurred. With multiple attempts, the attacker may be able to guesses the correct 
         password/response to challenge and elevate their privileges.

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

Consequences:
  - Confidentiality: Bypass Protection Mechanism

Mitigations:
  - [Implementation] The hardware designer should ensure that comparison logic is implemented so as to compare in one operation instead in smaller chunks.

Real-world examples:
  - CVE-2019-10482: Smartphone OS uses comparison functions that are not in constant time, allowing side channels
  - CVE-2019-10071: Java-oriented framework compares HMAC signatures  using  String.equals() instead of a constant-time algorithm, causing timing discrepancies
  - CVE-2014-0984: Password-checking function in router terminates validation of a password entry when it encounters the first incorrect character, which allows remote attackers to obtain passwords via a brute-force att
CWE-1257: Improper Access Control Applied to Mirrored or Aliased Memory Regions

Description:
Aliased or mirrored memory regions in hardware designs may have inconsistent read/write permissions enforced by the hardware. A possible result is that an untrusted agent is blocked from accessing a memory region but is not blocked from accessing the corresponding aliased memory region.

Extended Description:
Hardware product designs often need to implement memory protection features that enable privileged software to define isolated memory regions and access control (read/write) policies. Isolated memory regions can be defined on different memory spaces in a design (e.g. system physical address, virtual address, memory mapped IO). 
				 Each memory cell should be mapped and assigned a system address that the core software can use to read/write to that memory. It is possible to map the same memory cell to multiple system addresses such that read/write to any of the aliased system addresses would be decoded to the same memory cell. 
				 This is commonly done in hardware designs for redundancy and simplifying address decoding logic. If one of the memory regions is corrupted or faulty, then that hardware can switch to using the data in the mirrored memory region. Memory aliases can also be created in the system address map if the address decoder unit ignores higher order address bits when map

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

Consequences:
  - Confidentiality: Read Memory
  - Integrity: Modify Memory
  - Availability: DoS: Instability

Mitigations:
  - [Architecture and Design] The checks should be applied for consistency access rights between primary memory regions and any mirrored or aliased memory regions. If different memory protection units (MPU) are protecting the aliased regions, their protected range definitions and policies should be synchronized.
  - [Architecture and Design] The controls that allow enabling memory aliases or changing the size of mapped memory regions should only be programmable by trusted software components.

Demonstrative examples:
In a System-on-a-Chip (SoC) design the system fabric uses 16 bit addresses. An IP unit (Unit_A) has 4 kilobyte of internal memory which is mapped into a 16 kilobyte address range in the system fabric address map. 
						 
							 
								 
									System Address
								 
								 
									Mapped to
								 
							 
							 
								 
									0x0000 - 0x3FFF
								 
								 
									Unit_A  registers : 0x0000 - 0x0FFF
								 
							 
							 
								 
									0x4000 - 0xFFFF
								 
								 
									Other IPs & Memory
								 
							 
						 
						 
							To protect the register controls in Unit_A unprivileged software is blocked from accessing addresses between 0x0000 - 0x0FFF.
						 
						 
							The address decoder of Unit_A masks off the higher order address b