deardaniel/secdata-raw huggingface dataset:
CWE-1270: Generation of Incorrect Security Tokens

Description:
The product implements a Security Token mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Tokens generated in the system are incorrect.

Extended Description:
Systems-On-a-Chip (SoC) (Integrated circuits and hardware engines) implement Security Tokens to differentiate and identify actions originated from various agents. These actions could be "read", "write", "program", "reset", "fetch", "compute", etc. Security Tokens are generated and assigned to every agent on the SoC that is either capable of generating an action or receiving an action from another agent. Every agent could be assigned a unique, Security Token based on its trust level or privileges.

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

Consequences:
  - Confidentiality: Modify Files or Directories

Mitigations:
  - [Architecture and Design] Generation of Security Tokens should be reviewed for design inconsistency and common weaknesses. 
							 Security-Token definition and programming flow should be tested in pre-silicon and post-silicon testing.

Demonstrative examples:
Consider a system with a register for storing an AES key for encryption or decryption. The key is 128 bits long implemented as a set of four 32-bit registers. The key registers are assets, and register, AES_KEY_ACCESS_POLICY, is defined to provide necessary access controls. The access-policy register defines which agents, using a Security Token, may access the AES-key registers. Each bit in this 32-bit register is used to define a Security Token. There could be a maximum of 32 Security Tokens that are allowed access to the AES-key registers. When set (bit = "1") bit number allows action from an agent whose identity matches that bit number. If Clear (bit = "0") the action is disallowed for the corresponding agent.
Assume the system has two agents: a Main-controller and an Aux-controller. Th
CWE-1271: Uninitialized Value on Reset for Registers Holding Security Settings

Description:
Security-critical logic is not set to a known value on reset.

Extended Description:
When the device is first brought out of reset, the state of registers will be indeterminate if they have not been initialized by the logic. Before the registers are initialized, there will be a window during which the device is in an insecure state and may be vulnerable to attack.

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

Consequences:
  - Access Control: Varies by Context

Mitigations:
  - [Implementation] Design checks should be performed to identify any uninitialized flip-flops used for security-critical functions.
  - [Architecture and Design] All registers holding security-critical information should be set to a specific value on reset.

Demonstrative examples:
Shown below is a positive clock edge triggered flip-flop used to implement a lock bit for test and debug interface. When the circuit is first brought out of reset, the state of the flip-flop will be unknown until the enable input and D-input signals update the flip-flop state. In this example, an attacker can reset the device until the test and debug interface is unlocked and access the test interface until the lock signal is driven to a known state by the logic.
The flip-flop can be set to a known value (0 or 1) on reset, but requires that the logic explicitly update the output of the flip-flop if the reset signal is active.
always @(posedge clk) begin 
					     
					      if (en) lock_jtag <= d; 
					     
					    end
always @(posedge clk) begin 
					   
					    if (~reset) lock_jt
CWE-1272: Sensitive Information Uncleared Before Debug/Power State Transition

Description:
The product performs a power or debug state transition, but it does not clear sensitive information that should no longer be accessible due to changes to information access restrictions.

Extended Description:
A device or system frequently employs many power and sleep states during its normal operation (e.g., normal power, additional power, low power, hibernate, deep sleep, etc.). A device also may be operating within a debug condition. State transitions can happen from one power or debug state to another. If there is information available in the previous state which should not be available in the next state and is not properly removed before the transition into the next state, sensitive information may leak from the system.

Affected languages: VHDL, Verilog, Hardware Description Language
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-226

Consequences:
  - Confidentiality: Read Memory

Detection methods:
  - Manual Analysis: Write a known pattern into each sensitive location. Enter the power/debug state in question. Read data back from the sensitive locations. If the reads are successful, and the data is the same as the p

Mitigations:
  - [Architecture and Design] During state transitions, information not needed in the next state should be removed before the transition to the next state.

Demonstrative examples:
This example shows how an attacker can take advantage of an incorrect state transition.
Suppose a device is transitioning from state A to state B. During state A, it can read certain private keys from the hidden fuses that are only accessible in state A but not in state B. The device reads the keys, performs operations using those keys, then transitions to state B, where those private keys should no longer be accessible.
During the transition from A to B, the device does not scrub the memory.
For transition from state A to state B, remove information which should not be available once the transition is complete.

Real-world examples:
  - CVE-2020-12926: Product software does not set a flag as per TPM specifications, thereby preventing a failed authorization attempt from being recorded after a loss of power.
CWE-1273: Device Unlock Credential Sharing

Description:
The credentials necessary for unlocking a device are shared across multiple parties and may expose sensitive information.

Extended Description:
"Unlocking a device" often means activating certain unadvertised debug and manufacturer-specific capabilities of a device using sensitive credentials. Unlocking a device might be necessary for the purpose of troubleshooting device problems. For example, suppose a device contains the ability to dump the content of the full system memory by disabling the memory-protection mechanisms. Since this is a highly security-sensitive capability, this capability is "locked" in the production part. Unless the device gets unlocked by supplying the proper credentials, the debug capabilities are not available. For cases where the chip designer, chip manufacturer (fabricator), and manufacturing and assembly testers are all employed by the same company, the risk of compromise of the credentials is greatly reduced. However, the risk is greater when the chip designer is employed by one company, the chip manufacturer is employed by another company (a foundry), and the assemblers and testers are employed by

Affected languages: VHDL, Verilog, Compiled
Affected technologies: Other, Not Technology-Specific
Parent weaknesses: CWE-200

Consequences:
  - Confidentiality: Modify Memory

Mitigations:
  - [Integration] Ensure the unlock credentials are shared with the minimum number of parties and with utmost secrecy. To limit the risk associated with compromised credentials, where possible, the credentials should be part-specific.
  - [Manufacturing] Ensure the unlock credentials are shared with the minimum number of parties and with utmost secrecy. To limit the risk associated with compromised credentials, where possible, the credentials should be part-specific.

Demonstrative examples:
This example shows how an attacker can take advantage of compromised credentials.
When the credentials of multiple organizations are stored together, exposure to third parties occurs frequently.
Suppose a semiconductor chipmaker, "C", uses the foundry "F" for fabricating its chips. Now, F has many other customers in addition to C, and some of the other customers are much smaller companies. F has dedicated teams for each of its customers, but somehow it mixes up the unlock credentials and sends the unlock credentials of C to the wrong team. This other team does not take adequate precautions to protect the credentials that have nothing to do with them, and eventually the unlock credentials of C get leaked.
Vertical integration of a production company is one effective method of protecting sen
CWE-1274: Improper Access Control for Volatile Memory Containing Boot Code

Description:
The product conducts a secure-boot process that transfers bootloader code from Non-Volatile Memory (NVM) into Volatile Memory (VM), but it does not have sufficient access control or other protections for the Volatile Memory.

Extended Description:
Adversaries could bypass the secure-boot process and execute their own untrusted, malicious boot code. 
			   As a part of a secure-boot process, the read-only-memory (ROM) code for a System-on-Chip (SoC) or other system fetches bootloader code from Non-Volatile Memory (NVM) and stores the code in Volatile Memory (VM), such as dynamic, random-access memory (DRAM) or static, random-access memory (SRAM). The NVM is usually external to the SoC, while the VM is internal to the SoC. As the code is transferred from NVM to VM, it is authenticated by the SoC's ROM code.

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

Consequences:
  - Access Control: Modify Memory

Detection methods:
  - Manual Analysis: Ensure the volatile memory is lockable or has locks. Ensure the volatile memory is locked for writes from untrusted agents or adversaries. Try modifying the volatile memory from an untrusted agent, an
  - Manual Analysis: Analyze the device using the following steps: 
			       
				 Identify all fabric master agents that are active during system Boot Flow when initial code is loaded from Non-volatile storage to volati

Mitigations:
  - [Architecture and Design] Ensure that the design of volatile-memory protections is enough to prevent modification from an adversary or untrusted code.
  - [Testing] Test the volatile-memory protections to ensure they are safe from modification or untrusted code.

Demonstrative examples:
A typical SoC secure boot's flow includes fetching the next piece of code (i.e., the boot loader) from NVM (e.g., serial, peripheral interface (SPI) flash), and transferring it to DRAM/SRAM volatile, internal memory, which is more efficient.
The memory from where the boot loader executes can be modified by an adversary.
The volatile-memory protections or access controls are insufficient.
A good architecture should define appropriate protections or access controls to prevent modification by an adversary or untrusted agent, once the bootloader is authenticated.

Real-world examples:
  - CVE-2019-2267: Locked memory regions may be modified through other interfaces in a secure-boot-loader image due to improper access control.
CWE-1275: Sensitive Cookie with Improper SameSite Attribute

Description:
The SameSite attribute for sensitive cookies is not set, or an insecure value is used.

Extended Description:
The SameSite attribute controls how cookies are sent for cross-domain requests. This attribute may have three values: 'Lax', 'Strict', or 'None'. If the 'None' value is used, a website may create a cross-domain POST HTTP request to another website, and the browser automatically adds cookies to this request. This may lead to Cross-Site-Request-Forgery (CSRF) attacks if there are no additional protections in place (such as Anti-CSRF tokens).

Affected languages: Not Language-Specific
Affected technologies: Web Based, Web Server
Parent weaknesses: CWE-923

Consequences:
  - Confidentiality: Modify Application Data

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] Set the SameSite attribute of a sensitive cookie to 'Lax' or 'Strict'. This instructs the browser to apply this cookie only to same-domain requests, which provides a good Defense in Depth against CSRF attacks. When the 'Lax' value is in use, cookies are also sent for top-level cross-domain navigatio

Demonstrative examples:
In this example, a cookie is used to store a session ID for a client's interaction with a website. The snippet of code below establishes a new cookie to hold the sessionID.
Since the sameSite attribute is not specified, the cookie will be sent to the website with each request made by the client. An attacker can potentially perform a CSRF attack by using the following malicious page:
let sessionId = generateSessionId() 
                 let cookieOptions = { domain: 'example.com' } 
                 response.cookie('sessionid', sessionId, cookieOptions)
<html> 
		   
                    <form id=evil action="http://local:3002/setEmail" method="POST"> 
		     
		      <input type="hidden" name="newEmail" value="abc@example.com" /> 
		     
                    </form> 
		   
                 

Real-world examples:
  - CVE-2022-24045: Web application for a room automation system has client-side JavaScript that sets a sensitive cookie without the SameSite security attribute, allowing the cookie to be sniffed
CWE-1276: Hardware Child Block Incorrectly Connected to Parent System

Description:
Signals between a hardware IP and the parent system design are incorrectly connected causing security risks.

Extended Description:
Individual hardware IP must communicate with the parent system in order for the product to function correctly and as intended. If implemented incorrectly, while not causing any apparent functional issues, may cause security issues. For example, if the IP should only be reset by a system-wide hard reset, but instead the reset input is connected to a software-triggered debug mode reset (which is also asserted during a hard reset), integrity of data inside the IP can be violated.

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

Consequences:
  - Confidentiality: Varies by Context

Mitigations:
  - [Testing] System-level verification may be used to ensure that components are correctly connected and that design security requirements are not violated due to interactions between various IP blocks.

Demonstrative examples:
Many SoCs use hardware to partition system resources between trusted and untrusted entities. One example of this concept is the Arm TrustZone, in which the processor and all security-aware IP attempt to isolate resources based on the status of a privilege bit. This privilege bit is part of the input interface in all TrustZone-aware IP. If this privilege bit is accidentally grounded or left unconnected when the IP is instantiated, privilege escalation of all input data may occur.
In the Verilog code below, the security level input to the TrustZone aware peripheral is correctly driven by an appropriate signal instead of being grounded.
// IP definition 
			      module tz_peripheral(clk, reset, data_in, data_in_security_level, ...); 
			       
				input clk, reset; 
				input [31:0] data_in

Here is a code snippet from the Ariane core module in the HACK@DAC'21 Openpiton SoC [REF-1362]. 
				To ensure full functional correctness, developers connect the ports with names. However, in some cases developers forget to connect some of these ports to the desired signals in the parent module. These mistakes by developers can lead to incorrect functional behavior or, in some cases, introduce security vulnerabilities.
In the above example from HACK@DAC'21, since interrupt signals are not properly connected, the CSR module will fail to send notifications in the event of interrupts. Consequently, critical information in CSR registers that should be flushed or modified in response to an interrupt won't be updated. These vulnerabilities can potentially result in information leakage across va
CWE-1277: Firmware Not Updateable

Description:
The product does not provide its
			users with the ability to update or patch its
			firmware to address any vulnerabilities or
			weaknesses that may be present.

Extended Description:
Without the ability to
			patch or update firmware, consumers will be
			left vulnerable to exploitation of any known
			vulnerabilities, or any vulnerabilities that
			are discovered in the future. This can expose
			consumers to permanent risk throughout the
			entire lifetime of the device, which could be
			years or decades. Some external protective
			measures and mitigations might be employed to
			aid in preventing or reducing the risk of
			malicious attack, but the root weakness cannot
			be corrected.

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

Consequences:
  - Confidentiality: Gain Privileges or Assume Identity

Detection methods:
  - Manual Analysis: Create a new installable boot image of the current build with a minor version number change. Use the standard installation method to update the boot image. Verify that the minor version number has cha
  - Architecture or Design Review: Check the consumer or maintainer documentation, the architecture/design documentation, or the original requirements to ensure that the documentation includes details for how to update the firmware.
  - Manual Dynamic Analysis: Determine if there is a lack of a capability to update read-only memory (ROM) structure. This could manifest as a difference between the latest firmware version and the current version within the devi

Mitigations:
  - [Requirements] Specify requirements to include the ability to update the firmware. Include integrity checks and authentication to ensure that untrusted firmware cannot be installed.
  - [Architecture and Design] Design the device to allow for updating the firmware. Ensure that the design specifies how to distribute the updates and ensure their integrity and authentication.
  - [Implementation] Implement the necessary functionality to allow the firmware to be updated.

Demonstrative examples:
A refrigerator has an Internet interface for the official purpose of alerting the manufacturer when that refrigerator detects a fault. Because the device is attached to the Internet, the refrigerator is a target for hackers who may wish to use the device other potentially more nefarious purposes.

The refrigerator has no means of patching and is hacked, becoming a spewer of email spam.
The device automatically patches itself and provides considerable more protection against being hacked.

Real-world examples:
  - CVE-2020-9054: Chain: network-attached storage (NAS) device has a critical OS command injection (CWE-78) vulnerability that is actively exploited to place IoT devices into a botnet, but some products are "end-of-sup
  - [REF-1095]: A hardware "smart lock" has weak key generation that allows attackers to steal the key by BLE sniffing, but the device's firmware cannot be upgraded and hence remains vulnerable [REF-1095].
CWE-1278: Missing Protection Against Hardware Reverse Engineering Using Integrated Circuit (IC) Imaging Techniques

Description:
Information stored in hardware may be recovered by an attacker with the capability to capture and analyze images of the integrated circuit using techniques such as scanning electron microscopy.

Extended Description:
The physical structure of a device, viewed at high enough magnification, can reveal the information stored inside. Typical steps in IC reverse engineering involve removing the chip packaging (decapsulation) then using various imaging techniques ranging from high resolution x-ray microscopy to invasive techniques involving removing IC layers and imaging each layer using a scanning electron microscope. 
				 The goal of such activities is to recover secret keys, unique device identifiers, and proprietary code and circuit designs embedded in hardware that the attacker has been unsuccessful at accessing through other means. These secrets may be stored in non-volatile memory or in the circuit netlist. Memory technologies such as masked ROM allow easier to extraction of secrets than One-time Programmable (OTP) memory.

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

Consequences:
  - Confidentiality: Varies by Context

Mitigations:
  - [Architecture and Design] The cost of secret extraction via IC reverse engineering should outweigh the potential value of the secrets being extracted. Threat model and value of secrets should be used to choose the technology used to safeguard those secrets. Examples include IC camouflaging and obfuscation, tamper-proof packa

Demonstrative examples:
Consider an SoC design that embeds a secret key in read-only memory (ROM). The key is baked into the design logic and may not be modified after fabrication causing the key to be identical for all devices.  An attacker in possession of the IC can decapsulate and delayer the device. After imaging the layers, computer vision algorithms or manual inspection of the circuit features locate the ROM and reveal the value of the key bits as encoded in the visible circuit structure of the ROM.
CWE-1279: Cryptographic Operations are run Before Supporting Units are Ready

Description:
Performing cryptographic operations without ensuring that the supporting inputs are ready to supply valid data may compromise the cryptographic result.

Extended Description:
Many cryptographic hardware units depend upon other hardware units to supply information to them to produce a securely encrypted result. For example, a cryptographic unit that depends on an external random-number-generator (RNG) unit for entropy must wait until the RNG unit is producing random numbers. If a cryptographic unit retrieves a private encryption key from a fuse unit, the fuse unit must be up and running before a key may be supplied.

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

Consequences:
  - Access Control: Varies by Context

Mitigations:
  - [Architecture and Design] Best practices should be used to design cryptographic systems.
  - [Implementation] Continuously ensuring that cryptographic inputs are supplying valid information is necessary to ensure that the encrypted output is secure.

Demonstrative examples:
The following pseudocode illustrates the weak encryption resulting from the use of a pseudo-random-number generator output.
In the example above, first a check of RNG ready is performed. If the check fails, the RNG is ignored and a hard coded value is used instead. The hard coded value severely weakens the encrypted output.
If random_number_generator_self_test_passed() == TRUE 
					  then Seed = get_random_number_from_RNG() 
					  else Seed = hardcoded_number
If random_number_generator_self_test_passed() == TRUE 
					  then Seed = get_random_number_from_RNG() 
					  else enter_error_state()