deardaniel/secdata-raw huggingface dataset:
CWE-1188: Initialization of a Resource with an Insecure Default

Description:
The product initializes or sets a resource with a default that is intended to be changed by the product's installer, administrator, or maintainer, but the default is not secure.

Affected languages: Not Language-Specific
Parent weaknesses: CWE-1419, CWE-344, CWE-665

Consequences:
  - Other: Varies by Context

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

Demonstrative examples:
This code attempts to login a user using credentials from a POST request:
Because the $authorized variable is never initialized, PHP will automatically set $authorized to any value included in the POST request if register_globals is enabled. An attacker can send a POST request with an unexpected third value 'authorized' set to 'true' and gain authorized status without supplying valid credentials.
// $user and $pass automatically set from POST request 
                     if (login_user($user,$pass)) { $authorized = true; } 
                     ... 
                     
                   if ($authorized) { generatePage(); }
$user = $_POST['user']; $pass = $_POST['pass']; $authorized = false; if (login_user($user,$pass)) { $authorized = true; } 
                   ...

Real-world examples:
  - CVE-2022-36349: insecure default variable initialization in BIOS firmware for a hardware board allows DoS
  - CVE-2022-42467: A generic database browser interface has a default mode that exposes a web server to the network, allowing queries to the database.
CWE-1189: Improper Isolation of Shared Resources on System-on-a-Chip (SoC)

Description:
The System-On-a-Chip (SoC) does not properly isolate shared resources between trusted and untrusted agents.

Extended Description:
A System-On-a-Chip (SoC) has a lot of functionality, but it may have a limited number of pins or pads. A pin can only perform one function at a time. However, it can be configured to perform multiple different functions. This technique is called pin multiplexing. Similarly, several resources on the chip may be shared to multiplex and support different features or functions. When such resources are shared between trusted and untrusted agents, untrusted agents may be able to access the assets intended to be accessed only by the trusted agents.

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

Consequences:
  - Access Control: Bypass Protection Mechanism
  - Integrity: Quality Degradation

Detection methods:
  - Automated Dynamic Analysis: Pre-silicon / post-silicon: Test access to shared systems resources (memory ranges, control registers, etc.) from untrusted software to verify that the assets are not incorrectly exposed to untrusted 

Mitigations:
  - [Architecture and Design] When sharing resources, avoid mixing agents of varying trust levels. 
                  Untrusted agents should not share resources with trusted agents.

Demonstrative examples:
Consider the following SoC
	      design. The Hardware Root of Trust (HRoT) local SRAM is memory mapped in the core{0-N}
	      address space. The HRoT allows or disallows access to private memory ranges, thus
	      allowing the sram to function as a mailbox for communication between untrusted and
	      trusted HRoT partitions.
We assume that the threat is from malicious software in
	      the untrusted domain. We assume this software has access
	      to the core{0-N} memory map and can be running at any
	      privilege level on the untrusted cores. The capability
	      of this threat in this example is communication to and
	      from the mailbox region of SRAM modulated by the
	      hrot_iface. To address this threat, information must not
	      enter or exit the shared region of S

Real-world examples:
  - CVE-2020-8698: Processor has improper isolation of shared resources allowing for information disclosure.
  - CVE-2019-6260: Baseboard Management Controller (BMC) device implements Advanced High-performance Bus (AHB) bridges that do not require authentication for arbitrary read and write access to the BMC's physical address
CWE-1190: DMA Device Enabled Too Early in Boot Phase

Description:
The product enables a Direct Memory Access (DMA) capable device before the security configuration settings are established, which allows an attacker to extract data from or gain privileges on the product.

Extended Description:
DMA is included in a number of devices because it allows
              data transfer between the computer and the connected device, using
              direct hardware access to read or write directly to main memory
              without any OS interaction. An attacker could exploit this to
              access secrets. Several virtualization-based mitigations have been introduced to thwart DMA attacks. These are usually
              configured/setup during boot time. However, certain IPs that are
              powered up before boot is complete (known as early boot IPs) may
              be DMA capable. Such IPs, if not trusted, could launch DMA
              attacks and gain access to assets that should otherwise be
              protected.

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

Consequences:
  - Access Control: Bypass Protection Mechanism

Mitigations:
  - [Architecture and Design] Utilize an IOMMU to orchestrate IO access from
                 the start of the boot process.
CWE-1192: Improper Identifier for IP Block used in System-On-Chip (SOC)

Description:
The System-on-Chip (SoC) does not have unique, immutable identifiers for each of its components.

Extended Description:
A System-on-Chip (SoC) comprises several components (IP) with varied
           trust requirements. It is required that each IP is identified
           uniquely and should distinguish itself from other entities in
           the SoC without any ambiguity. The unique secured identity is
           required for various purposes. Most of the time the identity is used
           to route a transaction or perform certain actions, including 
           resetting, retrieving a sensitive information, and acting upon or on
           behalf of something else. 
            There are several variants of this weakness: 
             
	       A "missing" identifier is when the SoC does not define
	      any mechanism to uniquely identify the IP. 
	       An "insufficient" identifier might provide
	      some defenses - for example, against the most common
	      attacks - but it does not protect against everything
	      that is intended. 
	       A "misconfigured" mechanism occurs when a mechanis

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

Consequences:
  - Access Control: Bypass Protection Mechanism

Mitigations:
  - [Architecture and Design] Every identity generated in the SoC should be unique and
                    immutable in hardware. The actions that an IP is trusted or
                    not trusted should be clearly defined, implemented,
                    configured, and tested. If the definition is implemented via a
CWE-1193: Power-On of Untrusted Execution Core Before Enabling Fabric Access Control

Description:
The product enables components that contain untrusted firmware before memory and fabric access controls have been enabled.

Extended Description:
After initial reset, System-on-Chip (SoC) fabric access controls and other
           security features need to be programmed by trusted firmware as part
           of the boot sequence. If untrusted IPs or peripheral microcontrollers
	   are enabled first, then the untrusted component can master
           transactions on the hardware bus and target memory or other assets to
           compromise the SoC boot firmware.

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

Consequences:
  - Access Control: Bypass Protection Mechanism

Mitigations:
  - [Architecture and Design] The boot sequence should enable fabric access controls and memory protections before enabling third-party hardware IPs and peripheral microcontrollers that use untrusted firmware.
CWE-12: ASP.NET Misconfiguration: Missing Custom Error Page

Description:
An ASP .NET application must enable custom error pages in order to prevent attackers from mining information from the framework's built-in responses.

Affected languages: ASP.NET
Parent weaknesses: CWE-756

Consequences:
  - Confidentiality: Read Application Data

Mitigations:
  - [System Configuration] Handle exceptions appropriately in source code. ASP .NET applications should be configured to use custom error pages instead of the framework default page.
  - [Architecture and Design] Do not attempt to process an error or attempt to mask it.
  - [Implementation] Verify return values are correct and do not supply sensitive information about the system.

Demonstrative examples:
The mode attribute of the <customErrors> tag in the Web.config file defines whether custom or default error pages are used.
In the following insecure ASP.NET application setting, custom error message mode is turned off. An ASP.NET error message with detailed stack trace and platform versions will be returned.
<customErrors mode="Off" />
<customErrors mode="RemoteOnly" />
CWE-1209: Failure to Disable Reserved Bits

Description:
The reserved bits in a hardware design are not disabled prior to production. Typically, reserved bits are used for future capabilities and should not support any functional logic in the design.   However, designers might covertly use these bits to debug or further develop new capabilities in production hardware. Adversaries with access to these bits will write to them in hopes of compromising hardware state.

Extended Description:
Reserved bits are labeled as such so they can be allocated for a later purpose. They are not to do anything in the current design.  However, designers might want to use these bits to debug or control/configure a future capability to help minimize time to market (TTM). If the logic being controlled by these bits is still enabled in production, an adversary could use the logic to induce unwanted/unsupported behavior in the hardware.

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

Consequences:
  - Confidentiality: Varies by Context

Mitigations:
  - [Architecture and Design] Include a feature to disable reserved bits.
  - [Integration] Any writes to these reserve bits are blocked (e.g., ignored, access-protected, etc.), or an exception can be asserted.

Demonstrative examples:
Assume a hardware Intellectual Property (IP) has address space 0x0-0x0F for its configuration registers, with the last one labeled reserved (i.e. 0x0F).  Therefore inside the Finite State Machine (FSM), the code is as follows:
An adversary may perform writes to reserved address space in hopes of changing the behavior of the hardware. In the code above, the GPIO pin should remain low for normal operation.  However, it can be asserted by accessing the reserved address space (0x0F).  This may be a concern if the GPIO state is being used as an indicator of health (e.g. if asserted the hardware may respond by shutting down or resetting the system, which may not be the correct action the system should perform). 
                         In the code below, the condition "register_address = 0X0F"
CWE-121: Stack-based Buffer Overflow

Description:
A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).

Affected languages: Memory-Unsafe, C, C++
Affected technologies: Not Technology-Specific
Parent weaknesses: CWE-788, CWE-787

Consequences:
  - Availability: Modify Memory
  - Integrity: Modify Memory
  - Integrity: Modify Memory

Detection methods:
  - Fuzzing: Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with rand
  - 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:
  - [Operation] Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detectio
  - [Architecture and Design] Use an abstraction library to abstract away risky APIs. Not a complete solution.
  - [Implementation] Implement and perform bounds checking on input.
  - [Implementation] Do not use dangerous functions such as gets. Use safer, equivalent functions which check for boundary errors.

Demonstrative examples:
While buffer overflow examples can be rather complex, it is possible to have very simple, yet still exploitable, stack-based buffer overflows:
The buffer size is fixed, but there is no guarantee the string in argv[1] will not exceed this size and cause an overflow.
#define BUFSIZE 256 int main(int argc, char **argv) { char buf[BUFSIZE]; strcpy(buf, argv[1]); }

This example takes an IP address from a user, verifies that it is well formed and then looks up the hostname and copies it into a buffer.
This function allocates a buffer of 64 bytes to store the hostname, however there is no guarantee that the hostname will not be larger than 64 bytes. If an attacker specifies an address which resolves to a very large hostname, then the function may overwrite sensitive data or even relinquish control flow to the attacker.
void host_lookup(char *user_supplied_addr){ 
                         struct hostent *hp; in_addr_t *addr; char hostname[64]; in_addr_t inet_addr(const char *cp); 
                            
                            /*routine that ensures user_supplied_addr is in the right format for conversion */ 
                            
     

Real-world examples:
  - CVE-2021-35395: Stack-based buffer overflows in SFK for wifi chipset used for IoT/embedded devices, as exploited in the wild per CISA KEV.
CWE-1222: Insufficient Granularity of Address Regions Protected by Register Locks

Description:
The product defines a large address region protected from modification by the same register lock control bit. This results in a conflict between the functional requirement that some addresses need to be writable by software during operation and the security requirement that the system configuration lock bit must be set during the boot process.

Extended Description:
Integrated circuits and hardware IPs can expose the device configuration controls that need to be programmed after device power reset by a trusted firmware or software module (commonly set by BIOS/bootloader) and then locked from any further modification. In hardware design, this is commonly implemented using a programmable lock bit which enables/disables writing to a protected set of registers or address regions. When the programmable lock bit is set, the relevant address region can be implemented as a hardcoded value in hardware logic that cannot be changed later. 
                 A problem can arise wherein the protected region definition is not granular enough. After the programmable lock bit has been set, then this new functionality cannot be implemented without change to the hardware design.

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

Consequences:
  - Access Control: Other

Mitigations:
  - [Architecture and Design] The defining of protected locked registers should be reviewed or tested early in the design phase with software teams to ensure software flows are not blocked by the security locks. 
                         As an alternative to using register lock control bits and fixed access control regions, the 

Demonstrative examples:
For example, consider a hardware unit with a 32 kilobyte configuration address space where the first 8 kilobyte address contains security sensitive controls that must only be writable by device bootloader. One way to protect the security configuration could be to define a 32 bit system configuration locking register (SYS_LOCK) where each bit lock locks the corresponding 1 kilobyte region.
If a register exists within the first kilobyte address range (e.g. SW_MODE, address 0x310) and needs to be software writable at runtime, then this register cannot be written in a securely configured system since SYS_LOCK register lock bit 0 must be set to protect other security settings (e.g. SECURITY_FEATURE_ENABLE, address 0x0004). The only fix would be to change the hardware logic or not set the securi
CWE-1223: Race Condition for Write-Once Attributes

Description:
A write-once register in hardware design is programmable by an untrusted software component earlier than the trusted software component, resulting in a race condition issue.

Extended Description:
Integrated circuits and hardware IP software programmable controls and settings are commonly stored in register circuits. These register contents have to be initialized at hardware reset to defined default values that are hard coded in the hardware description language (HDL) code of the hardware unit. A common security protection method used to protect register settings from modification by software is to make them write-once. This means the hardware implementation only allows writing to such registers once, and they become read-only after having been written once by software. This is useful to allow initial boot software to configure systems settings to secure values while blocking runtime software from modifying such hardware settings. 
                 Implementation issues in hardware design of such controls can expose such registers to a race condition security flaw. For example, consider a hardware design that has two different software/firmware modules executing in parallel. One

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

Consequences:
  - Access Control: Bypass Protection Mechanism

Detection methods:
  - Automated Analysis: The testing phase should use automated tools to test that values are not reprogrammable and that write-once fields lock on writing zeros.

Mitigations:
  - [Architecture and Design] During hardware design, all register write-once or sticky fields must be evaluated for proper configuration.

Demonstrative examples:
Consider the example design module system Verilog code shown below. register_write_once_example module is an example of register that has a write-once field defined. Bit 0 field captures the write_once_status value.
The first system component that sends a write cycle to this register can program the value. This could result in a race condition security issue in the SoC design, if an untrusted agent is running in the system in parallel with the trusted component that is expected to program the register.
module register_write_once_example 
                        ( 
						 
                          input [15:0] Data_in, 
                          input Clk, 
                          input ip_resetn, 
                          input global_resetn, 
                          input write,
CWE-1224: Improper Restriction of Write-Once Bit Fields

Description:
The hardware design control register "sticky bits" or write-once bit fields are improperly implemented, such that they can be reprogrammed by software.

Extended Description:
Integrated circuits and hardware IP software programmable controls and settings are commonly stored in register circuits. These register contents have to be initialized at hardware reset to define default values that are hard coded in the hardware description language (HDL) code of the hardware unit. A common security protection method used to protect register settings from modification by software is to make the settings write-once or "sticky." This allows writing to such registers only once, whereupon they become read-only. This is useful to allow initial boot software to configure systems settings to secure values while blocking runtime software from modifying such hardware settings. 
                 Failure to implement write-once restrictions in hardware design can expose such registers to being re-programmed by software and written multiple times. For example, write-once fields could be implemented to only be write-protected if they have been set to value "1", wherein they would

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

Consequences:
  - Confidentiality: Varies by Context

Detection methods:
  - Automated Analysis: Use automated tools to test that values are not reprogrammable and that write-once fields lock on writing zeros.

Mitigations:
  - [Architecture and Design] During hardware design, all register write-once or sticky fields must be evaluated for proper configuration.

Demonstrative examples:
Consider the example design module system verilog code shown below. register_write_once_example module is an example of register that has a write-once field defined. Bit 0 field captures the write_once_status value. This implementation can be for a register that is defined by specification to be a write-once register, since the write_once_status field gets written by input data bit 0 on first write.
The above example only locks further writes if write_once_status bit is written to one. So it acts as write_1-Once instead of the write-once attribute.
module register_write_once_example 
		      (  
		      input [15:0] Data_in,  
		      input Clk,  
		      input ip_resetn,  
		      input global_resetn, 
		      input write, 
		      output reg [15:0] Data_out  
		      );
CWE-1229: Creation of Emergent Resource

Description:
The product manages resources or behaves in a way that indirectly creates a new, distinct resource that can be used by attackers in violation of the intended policy.

Extended Description:
A product is only expected to behave in a way that was specifically intended by the developer.  Resource allocation and management is expected to be performed explicitly by the associated code.  However, in systems with complex behavior, the product might indirectly produce new kinds of resources that were never intended in the original design.  For example, a covert channel is a resource that was never explicitly intended by the developer, but it is useful to attackers.  "Parasitic computing," while not necessarily malicious in nature, effectively tricks a product into performing unintended computations on behalf of another party.

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

Consequences:
  - Other: Varies by Context

Demonstrative examples:
In this example, the attacker observes how long an authentication takes when the user types in the correct password.
When the attacker tries their own values, they can first try strings of various length. When they find a string of the right length, the computation will take a bit longer, because the for loop will run at least once. Additionally, with this code, the attacker can possibly learn one character of the password at a time, because when they guess the first character right, the computation will take longer than a wrong guesses. Such an attack can break even the most sophisticated password with a few hundred guesses.
def validate_password(actual_pw, typed_pw):
		  
                    if len(actual_pw) <> len(typed_pw):
		    return 0 
                    for i in len(actual_pw):