deardaniel/secdata-raw huggingface dataset:
CWE-123: Write-what-where Condition

Description:
Any condition where the attacker has the ability to write an arbitrary value to an arbitrary location, often as the result of a buffer overflow.

Affected languages: Memory-Unsafe, C, C++
Parent weaknesses: CWE-787, CWE-787, CWE-119

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

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

Mitigations:
  - [Architecture and Design] Use a language that provides appropriate memory abstractions.
  - [Operation] Use OS-level preventative functionality integrated after the fact. Not a complete solution.

Demonstrative examples:
The classic example of a write-what-where condition occurs when the accounting information for memory allocations is overwritten in a particular fashion. Here is an example of potentially vulnerable code:
Vulnerability in this case is dependent on memory layout. The call to strcpy() can be used to write past the end of buf1, and, with a typical layout, can overwrite the accounting information that the system keeps for buf2 when it is allocated. Note that if the allocation header for buf2 can be overwritten, buf2 itself can be overwritten as well.
#define BUFSIZE 256 int main(int argc, char **argv) { char *buf1 = (char *) malloc(BUFSIZE); char *buf2 = (char *) malloc(BUFSIZE); strcpy(buf1, argv[1]); free(buf2); }

Real-world examples:
  - CVE-2019-19911: Chain: Python library does not limit the resources used to process images that specify a very large number of bands (CWE-1284), leading to excessive memory consumption (CWE-789) or an integer overflow
  - CVE-2022-0545: Chain: 3D renderer has an integer overflow (CWE-190) leading to write-what-where condition (CWE-123) using a crafted image.
CWE-1230: Exposure of Sensitive Information Through Metadata

Description:
The product prevents direct access to a resource containing sensitive information, but it does not sufficiently limit access to metadata that is derived from the original, sensitive information.

Extended Description:
Developers might correctly prevent unauthorized access to a database or other resource containing sensitive information, but they might not consider that portions of the original information might also be recorded in metadata, search indices, statistical reports, or other resources.  If these resources are not also restricted, then attackers might be able to extract some or all of the original information, or otherwise infer some details.  For example, an attacker could specify search terms that are known to be unique to a particular person, or view metadata such as activity or creation dates in order to identify usage patterns.

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

Consequences:
  - Confidentiality: Read Application Data
CWE-1232: Improper Lock Behavior After Power State Transition

Description:
Register lock bit protection disables changes to system configuration once the bit is set. Some of the protected registers or lock bits become programmable after power state transitions (e.g., Entry and wake from low power sleep modes) causing the system configuration to be changeable.

Extended Description:
Devices may allow device configuration controls which need to be programmed after device power reset via a trusted firmware or software module (commonly set by BIOS/bootloader) and then locked from any further modification. This action is commonly implemented using a programmable lock bit, which, when set, disables writes to a protected set of registers or address regions. 
         After a power state transition, the lock bit is set to unlocked. Some common weaknesses that can exist in such a protection scheme are that the lock gets cleared, the values of the protected registers get reset, or the lock become programmable.

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

Consequences:
  - Access Control: Modify Memory

Mitigations:
  - [Architecture and Design] Security Lock bit protections should be reviewed for behavior across supported power state transitions. 
               Security lock programming flow and lock properties should be tested in pre-silicon and post-silicon testing including testing across power transitions.

Demonstrative examples:
Consider the memory configuration settings of a system that uses DDR3 DRAM memory. Protecting the DRAM memory configuration from modification by software is required to ensure that system memory access control protections cannot be bypassed. This can be done by using lock bit protection that locks all of the memory configuration registers. The memory configuration lock can be set by the BIOS during the boot process. 
             If such a system also supports a rapid power on mode like hibernate, the DRAM data must be saved to a disk before power is removed and restored back to the DRAM once the system powers back up and before the OS resumes operation after returning from hibernate.
To support the hibernate transition back to the operating state, the DRAM memory configuration must be rep

The example code below is taken from the register lock module (reglk_wrapper) of the Hack@DAC'21 buggy OpenPiton System-on-Chip (SoC). Upon powering on, most of the silicon registers are initially unlocked. However, critical resources must be configured and locked by setting the lock bit in a register.  
             In this module, a set of six memory-mapped I/O registers (reglk_mem) is defined and maintained to control the access control of registers inside different peripherals in the SoC [REF-1432].  Each bit represents a register's read/write ability or sets of registers inside a peripheral. Setting improper lock values after system power transition or system rest would make a temporary window for the attackers to read unauthorized data, e.g., secret keys from the crypto engine, and w
CWE-1233: Security-Sensitive Hardware Controls with Missing Lock Bit Protection

Description:
The product uses a register lock bit protection mechanism, but it does not ensure that the lock bit prevents modification of system registers or controls that perform changes to important hardware system configuration.

Extended Description:
Integrated circuits and hardware intellectual properties (IPs) might provide device configuration controls that need to be programmed after device power reset by a trusted firmware or software module, commonly set by BIOS/bootloader. After reset, there can be an expectation that the controls cannot be used to perform any further modification. This behavior is commonly implemented using a trusted lock bit, which can be set to disable writes to a protected set of registers or address regions. The lock protection is intended to prevent modification of certain system configuration (e.g., memory/memory protection unit configuration). 
		 However, if the lock bit does not effectively write-protect all system registers or controls that could modify the protected system configuration, then an adversary may be able to use software to access the registers/controls and modify the protected hardware configuration.

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

Consequences:
  - Access Control: Modify Memory

Detection methods:
  - Manual Analysis: Set the lock bit. Attempt to modify the
	     information protected by the lock bit. If the information
	     is changed, implement a design fix. Retest. Also, attempt
	     to indirectly clear the lo

Mitigations:
  - [Architecture and Design] Security lock bit protections must be reviewed for design inconsistency and common weaknesses. 
			     Security lock programming flow and lock properties must be tested in pre-silicon and post-silicon testing.

Demonstrative examples:
Consider the example design below for a digital thermal sensor that detects overheating of the silicon and triggers system shutdown. The system critical temperature limit (CRITICAL_TEMP_LIMIT) and thermal sensor calibration (TEMP_SENSOR_CALIB) data have to be programmed by the firmware.
In this example note that only the CRITICAL_TEMP_LIMIT register is protected by the TEMP_SENSOR_LOCK bit, while the security design intent is to protect any modification of the critical temperature detection and response. 
			    
			    The response of the system, if the system heats to a critical temperature, is controlled by TEMP_HW_SHUTDOWN bit [1], which is not lockable. Also, the TEMP_SENSOR_CALIB register is not protected by the lock bit.
			    
			    By modifying the temperature sensor calibration

Real-world examples:
  - CVE-2018-9085: Certain servers leave a write protection lock bit
		unset after boot, potentially allowing modification of
		parts of flash memory.
  - CVE-2014-8273: Chain: chipset has a race condition (CWE-362) between when an interrupt handler detects an attempt to write-enable the BIOS (in violation of the lock bit), and when the handler resets the write-enable
CWE-1234: Hardware Internal or Debug Modes Allow Override of Locks

Description:
System configuration protection may be bypassed during debug mode.

Extended Description:
Device configuration controls are commonly programmed after a device power reset by a trusted firmware or software module (e.g., BIOS/bootloader) and then locked from any further modification. This is commonly implemented using a trusted lock bit, which when set, disables writes to a protected set of registers or address regions. The lock protection is intended to prevent modification of certain system configuration (e.g., memory/memory protection unit configuration). If debug features supported by hardware or internal modes/system states are supported in the hardware design, modification of the lock protection may be allowed allowing access and modification of configuration information.

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

Consequences:
  - Access Control: Bypass Protection Mechanism

Mitigations:
  - [Architecture and Design] Security Lock bit protections should be reviewed for any bypass/override modes supported. 
           Any supported override modes either should be removed or protected using authenticated debug modes. 
           Security lock programming flow and lock properties should be tested in pre-silicon and

Demonstrative examples:
For example, consider the example Locked_override_register example. This register module supports a lock mode that blocks any writes after lock is set to 1.
         
         However, it also allows override of the lock protection when scan_mode or debug_unlocked modes are active.
If either the scan_mode or the debug_unlocked modes can be triggered by software, then the lock protection may be bypassed.
module Locked_register_example 
          ( 
		  input [15:0] Data_in, 
		  input Clk, 
		  input resetn, 
		  input write, 
		  input Lock, 
		  input scan_mode, 
		  input debug_unlocked, 
		  output reg [15:0] Data_out 
		  ); 
           
          reg lock_status; 
           
          always @(posedge Clk or negedge resetn) 
		   
			if (~resetn) // Register is reset resetn 
			begin

The following example code [REF-1375] is taken from the register lock security peripheral of the HACK@DAC'21 buggy OpenPiton SoC. It demonstrates how to lock read or write access to security-critical hardware registers (e.g., crypto keys, system integrity code, etc.). The configuration to lock all the sensitive registers in the SoC is managed through the reglk_mem registers. These reglk_mem registers are reset when the hardware powers up and configured during boot up. Malicious users, even with kernel-level software privilege, do not get access to the sensitive contents that are locked down. Hence, the security of the entire system can potentially be compromised if the register lock configurations are corrupted or if the register locks are disabled.
The example code [REF-1375] illustrates
CWE-1235: Incorrect Use of Autoboxing and Unboxing for Performance Critical Operations

Description:
The code uses boxed primitives, which may introduce inefficiencies into performance-critical operations.

Affected languages: Java, C#
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-400

Consequences:
  - Availability: DoS: Resource Consumption (CPU)

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

Mitigations:
  - [Implementation] Use of boxed primitives should be limited to certain situations such as when calling methods with typed parameters.  They should not be used for scientific computing or other performance critical operations. They are only suited to support "impedance mismatch" between reference types and primitives.

Demonstrative examples:
Java has a boxed primitive for each primitive type. A long can be represented with the boxed primitive Long. Issues arise where boxed primitives are used when not strictly necessary.
In the above loop, we see that the count variable is declared as a boxed primitive. This causes autoboxing on the line that increments. This causes execution to be magnitudes less performant (time and possibly space) than if the "long" primitive was used to declare the count variable, which can impact availability of a resource.
Long count = 0L;
					 
					for (long i = 0; i < Integer.MAX_VALUE; i++) {
					 
						count += i;
						 
					 
					}

This code uses primitive long which fixes the issue.

long count = 0L;
					 
					for (long i = 0; i < Integer.MAX_VALUE; i++) {
					 
						count += i;
						 
					 
					}
CWE-1236: Improper Neutralization of Formula Elements in a CSV File

Description:
The product saves user-provided information into a Comma-Separated Value (CSV) file, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as a command when the file is opened by a spreadsheet product.

Affected languages: Not Language-Specific
Affected technologies: Other
Parent weaknesses: CWE-74, CWE-74

Consequences:
  - Confidentiality: Read 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] When generating CSV output, ensure that formula-sensitive metacharacters are effectively escaped or removed from all data before storage in the resultant CSV.  Risky characters include '=' (equal), '+' (plus), '-' (minus), and '@' (at).
  - [Implementation] If a field starts with a formula character, prepend it with a ' (single apostrophe), which prevents Excel from executing the formula.
  - [Architecture and Design] Certain implementations of spreadsheet software might disallow formulas from executing if the file is untrusted, or if the file is not authored by the current user.

Demonstrative examples:
Hyperlinks or other commands can be executed when a cell begins with the formula identifier, '='
Stripping the leading equals sign, or simply not executing formulas from untrusted sources, impedes malicious activity.
=HYPERLINK(link_location, [friendly_name])
HYPERLINK(link_location, [friendly_name])

Real-world examples:
  - CVE-2019-12134: Low privileged user can trigger CSV injection through a contact form field value
  - CVE-2019-4521: Cloud management product allows arbitrary command execution via CSV injection
  - CVE-2019-17661: CSV injection in content management system via formula code in a first or last name
CWE-1239: Improper Zeroization of Hardware Register

Description:
The hardware product does not properly clear sensitive information from built-in registers when the user of the hardware block changes.

Extended Description:
Hardware logic operates on data stored in registers local to the hardware block. Most hardware IPs, including cryptographic accelerators, rely on registers to buffer I/O, store intermediate values, and interface with software. The result of this is that sensitive information, such as passwords or encryption keys, can exist in locations not transparent to the user of the hardware logic. When a different entity obtains access to the IP due to a change in operating mode or conditions, the new entity can extract information belonging to the previous user if no mechanisms are in place to clear register contents. It is important to clear information stored in the hardware if a physical attack on the product is detected, or if the user of the hardware block changes. The process of clearing register contents in a hardware IP is referred to as zeroization in standards for cryptographic hardware modules such as FIPS-140-2 [REF-267].

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

Consequences:
  - Confidentiality: Varies by Context

Mitigations:
  - [Architecture and Design] Every register potentially containing sensitive information must have a policy specifying how and when information is cleared, in addition to clarifying if it is the responsibility of the hardware logic or IP user to initiate the zeroization procedure at the appropriate time.

Demonstrative examples:
Suppose a hardware IP for implementing an encryption routine works as expected, but it leaves the intermediate results in some registers that can be accessed. Exactly why this access happens is immaterial - it might be unintentional or intentional, where the designer wanted a "quick fix" for something.

The example code below [REF-1379] is taken from the SHA256 Interface/wrapper controller module of the HACK@DAC'21 buggy OpenPiton SoC. Within the wrapper module there are a set of 16 memory-mapped registers referenced data[0] to data[15]. These registers are 32 bits in size and are used to store the data received on the AXI Lite interface for hashing. Once both the message to be hashed and a request to start the hash computation are received, the values of these registers will be forwarded to the underlying SHA256 module for processing. Once forwarded, the values in these registers no longer need to be retained. In fact, if not cleared or overwritten, these sensitive values can be read over the AXI Lite interface, potentially compromising any previously confidential data stored therein.
In
CWE-1241: Use of Predictable Algorithm in Random Number Generator

Description:
The device uses an algorithm that is predictable and generates a pseudo-random number.

Extended Description:
Pseudo-random number generator algorithms are predictable because their registers have a finite number of possible states, which eventually lead to repeating patterns. As a result, pseudo-random number generators (PRNGs) can compromise their randomness or expose their internal state to various attacks, such as reverse engineering or tampering.
Affected technologies: System on Chip
Parent weaknesses: CWE-330

Consequences:
  - Confidentiality: Read Application Data

Mitigations:
  - [Architecture and Design] It is highly recommended to use a true random number generator (TRNG) to ensure the security of encryption schemes. Hardware-based TRNGs generate unpredictable, unbiased, and independent random numbers because they employ physical phenomena, e.g., electrical noise, as sources to generate random numb
  - [Implementation] It is highly recommended to use a true random number generator (TRNG) to ensure the security of encryption schemes. Hardware-based TRNGs generate unpredictable, unbiased, and independent random numbers because they employ physical phenomena, e.g., electrical noise, as sources to generate random numb

Demonstrative examples:
Suppose a cryptographic function expects random value to be supplied for the crypto algorithm.
During the implementation phase, due to space constraint, a cryptographically secure random-number-generator could not be used, and instead  of using a TRNG (True Random Number Generator), a LFSR (Linear Feedback Shift Register) is used to generate a random value. While an LFSR will provide a pseudo-random number, its entropy (measure of randomness) is insufficient for a cryptographic algorithm.

The example code is taken from the PRNG inside the buggy OpenPiton SoC of HACK@DAC'21 [REF-1370]. The SoC implements a pseudo-random number generator using a Linear Feedback Shift Register (LFSR).

reg in_sr, entropy16_valid; 
						 reg [15:0] entropy16; 
						 
						 assign entropy16_o = entropy16; 
						 assign entropy16_valid_o = entropy16_valid; 
						 
						 always @ (*) 
						 begin 
						 
							 in_sr = ^ (poly_i [15:0] & entropy16 [15:0]); 
						 
						 end

Real-world examples:
  - CVE-2021-3692: PHP framework uses mt_rand() function (Marsenne Twister) when generating tokens
CWE-1242: Inclusion of Undocumented Features or Chicken Bits

Description:
The device includes chicken bits or undocumented features that can create entry points for unauthorized actors.

Extended Description:
A common design practice is to use undocumented bits on a device that can be used to disable certain functional security features. These bits are commonly referred to as "chicken bits". They can facilitate quick identification and isolation of faulty components, features that negatively affect performance, or features that do not provide the required controllability for debug and test. Another way to achieve this is through implementation of undocumented features.

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific, ICS/OT
Parent weaknesses: CWE-912

Consequences:
  - Confidentiality: Modify Memory

Mitigations:
  - [Architecture and Design] The implementation of chicken bits in a released product is highly discouraged. If implemented at all, ensure that they are disabled in production devices. All interfaces to a device should be documented.

Demonstrative examples:
Consider a device that comes with various security measures, such as secure boot. The secure-boot process performs firmware-integrity verification at boot time, and this code is stored in a separate SPI-flash device. However, this code contains undocumented "special access features" intended to be used only for performing failure analysis and intended to only be unlocked by the device designer.
Remove all chicken bits and hidden features that are exposed to attackers. Add authorization schemes that rely on cryptographic primitives to access any features that the manufacturer does not want to expose. Clearly document all interfaces.
Attackers dump the code from the device and then perform reverse engineering to analyze the code. The undocumented, special-access features are identified, and