deardaniel/secdata-raw huggingface dataset:
CWE-1320: Improper Protection for Outbound Error Messages and Alert Signals

Description:
Untrusted agents can disable alerts about signal conditions exceeding limits or the response mechanism that handles such alerts.

Extended Description:
Hardware sensors are used to detect whether a device is operating within design limits. The threshold values for these limits are set by hardware fuses or trusted software such as a BIOS.  
				Modification of these limits may be protected by hardware mechanisms. 
				 When device sensors detect out of bound conditions, alert signals may be generated for remedial action, which may take the form of device shutdown or throttling. 
				 Warning signals that are not properly secured may be disabled or used to generate spurious alerts, causing degraded performance or denial-of-service (DoS).
				These alerts may be masked by untrusted software. Examples of these alerts involve thermal and power sensor alerts.

Affected languages: Not Language-Specific
Affected technologies: System on Chip, Microcontroller Hardware, Memory Hardware, Power Management Hardware, Processor Hardware, Test/Debug Hardware, Sensor Hardware
Parent weaknesses: CWE-284

Consequences:
  - Availability: DoS: Instability

Mitigations:
  - [Architecture and Design] Alert signals generated by critical events should be protected from access by untrusted agents. Only hardware or trusted firmware modules should be able to alter the alert configuration.

Demonstrative examples:
Consider a platform design where a Digital-Thermal Sensor (DTS) is used to monitor temperature and compare that output against a threshold value.
							If the temperature output equals or exceeds the threshold value, the DTS unit sends an alert signal to the processor. 
						 The processor, upon getting the alert, input triggers system shutdown. The alert signal is handled as a General-Purpose-I/O (GPIO) pin in input mode.
Reprogramming the state of the GPIO pin allows malicious software to trigger spurious alerts or to set the alert pin to a zero value so that thermal sensor alerts are not received by the processor.
The processor-GPIO controller exposes software-programmable controls that allow untrusted software to reprogram the state of the GPIO pin.
The GPIO alert-signal pin is block
CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')

Description:
The product receives input from an upstream component that specifies attributes that are to be initialized or updated in an object, but it does not properly control modifications of attributes of the object prototype.

Affected languages: JavaScript
Parent weaknesses: CWE-915, CWE-913

Consequences:
  - Confidentiality: Read Application Data
  - Availability: DoS: Crash, Exit, or Restart

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

Mitigations:
  - [Implementation] By freezing the object prototype first (for example, Object.freeze(Object.prototype)), modification of the prototype becomes impossible.
  - [Architecture and Design] By blocking modifications of attributes that resolve to object prototype, such as proto or prototype, this weakness can be mitigated.
  - [Implementation] When handling untrusted objects, validating using a schema can be used.
  - [Implementation] By using an object without prototypes (via Object.create(null) ), adding object prototype attributes by accessing the prototype via the special attributes becomes impossible, mitigating this weakness.

Demonstrative examples:
This function sets object attributes based on a dot-separated path.
This function does not check if the attribute resolves to the object prototype. These codes can be used to add "isAdmin: true" to the object prototype.
function setValueByPath (object, path, value) { 
					 
					    const pathArray = path.split("."); 
					    const attributeToSet = pathArray.pop(); 
					    let objectToModify = object; 
					    for (const attr of pathArray) { 
					     if (typeof objectToModify[attr] !== 'object') { 
					     objectToModify[attr] = {}; 
					        } 
					        objectToModify = objectToModify[attr]; 
					    } 
					    objectToModify[attributeToSet] = value; 
					    return object; 
					}
setValueByPath({}, "__proto__.isAdmin", true) 
					  setValueByPath({}, "constructor.pr

Real-world examples:
  - CVE-2018-3721: Prototype pollution by merging objects.
  - CVE-2019-10744: Prototype pollution by setting default values to object attributes recursively.
  - CVE-2019-11358: Prototype pollution by merging objects recursively.
  - CVE-2020-8203: Prototype pollution by setting object attributes based on dot-separated path.
CWE-1322: Use of Blocking Code in Single-threaded, Non-blocking Context

Description:
The product uses a non-blocking model that relies on a single threaded process
			for features such as scalability, but it contains code that can block when it is invoked.

Extended Description:
When an attacker can directly invoke the blocking code, or the blocking code can be affected by environmental conditions that can be influenced by an attacker, then this can lead to a denial of service by causing unexpected hang or freeze of the code. Examples of blocking code might be an expensive computation or calling
				blocking library calls, such as those that perform exclusive file operations or require a successful network operation. 
				 Due to limitations in multi-thread models, single-threaded
				models are used to overcome the resource constraints that are caused by using
				many threads. In such a model, all code should generally be
				non-blocking. If blocking code is called, then the event loop will
				effectively be stopped, which can be undesirable or dangerous.  Such
				models are used in Python asyncio, Vert.x, and Node.js, or other
				custom event loop code.

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

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

Mitigations:
  - [Implementation] Generally speaking, blocking calls should be
					replaced with non-blocking alternatives that can be used asynchronously.
					Expensive computations should be passed off to worker threads, although
					the correct approach depends on the framework being used.
  - [Implementation] For expensive computations, consider breaking them up into
					multiple smaller computations. Refer to the documentation of the
					framework being used for guidance.
CWE-1323: Improper Management of Sensitive Trace Data

Description:
Trace data collected from several sources on the
                System-on-Chip (SoC) is stored in unprotected locations or
                transported to untrusted agents.

Extended Description:
To facilitate verification of complex System-on-Chip
                    (SoC) designs, SoC integrators add specific IP blocks that
                    trace the SoC's internal signals in real-time. This
                    infrastructure enables observability of the SoC's internal
                    behavior, validation of its functional design,
                    and detection of hardware and software bugs. Such tracing
                    IP blocks collect traces from several sources on the SoC
                    including the CPU, crypto coprocessors, and on-chip fabrics. Traces collected from these sources are then
                    aggregated inside trace IP block and forwarded to trace
                    sinks, such as debug-trace ports that facilitate debugging by
                    external hardware and software debuggers. 
					 Since
                    these traces are collected from several security-sensitive
                    sources, they must be protected again

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

Consequences:
  - Confidentiality: Read Memory

Mitigations:
  - [Implementation] Tag traces to indicate owner and debugging privilege level (designer, OEM, or end user) needed to access that trace.

Demonstrative examples:
In a SoC, traces generated from sources
                        include security-sensitive IP blocks such as CPU (with
                        tracing information such as instructions executed and
                        memory operands), on-chip fabric (e.g., memory-transfer
                        signals, transaction type and destination, and
                        on-chip-firewall-error signals), power-management
                        IP blocks (e.g., clock- and power-gating signals), and
                        cryptographic coprocessors (e.g., cryptographic keys and
                        intermediate values of crypto operations), among
                        other non-security-sensitive IP blocks including timers
                        and other functional blocks. The collecte
CWE-1325: Improperly Controlled Sequential Memory Allocation

Description:
The product manages a group of objects or resources and performs a separate memory allocation for each object, but it does not properly limit the total amount of memory that is consumed by all of the combined objects.

Extended Description:
While the product might limit the amount of memory that is allocated in a single operation for a single object (such as a malloc of an array), if an attacker can cause multiple objects to be allocated in separate operations, then this might cause higher total memory consumption than the developer intended, leading to a denial of service.

Affected languages: C, C++, Not Language-Specific
Parent weaknesses: CWE-770

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

Mitigations:
  - [Implementation] Ensure multiple allocations of the same kind of object are properly tracked - possibly across multiple sessions, requests, or messages. Define an appropriate strategy for handling requests that exceed the limit, and consider supporting a configuration option so that the administrator can extend the 
  - [Operation] Run the program using system-provided resource limits for memory. This might still cause the program to crash or exit, but the impact to the rest of the system will be minimized.

Demonstrative examples:
This example contains a small allocation of stack memory. When the program was first constructed, the number of times this memory was allocated was probably inconsequential and presented no problem. Over time, as the number of objects in the database grow, the number of allocations will grow - eventually consuming the available stack, i.e. "stack exhaustion." An attacker who is able to add elements to the database could cause stack exhaustion more rapidly than assumed by the developer.
Since this uses alloca(), it allocates memory directly on the stack.  If end_limit is large enough, then the stack can be entirely consumed.
// Gets the size from the number of objects in a database, which over time can conceivably get very large 
					  int end_limit = get_nmbr_obj_from_db(); 
					  int i;

Real-world examples:
  - CVE-2020-36049: JavaScript-based packet decoder uses concatenation of many small strings, causing out-of-memory (OOM) condition
  - CVE-2019-20176: Product allocates a new buffer on the stack for each file in a directory, allowing stack exhaustion
  - CVE-2013-1591: Chain: an integer overflow (CWE-190) in the image size calculation causes an infinite loop (CWE-835) which sequentially allocates buffers without limits (CWE-1325) until the stack is full.
CWE-1327: Binding to an Unrestricted IP Address

Description:
The product assigns the address 0.0.0.0 for a database server, a cloud service/instance, or any computing resource that communicates remotely.

Extended Description:
When a server binds to the address 0.0.0.0, it allows connections from every IP address on the local machine, effectively exposing the server to every possible network. This might be much broader access than intended by the developer or administrator, who might only be expecting the server to be reachable from a single interface/network.

Affected languages: Other
Affected technologies: Web Server, Client Server, Cloud Computing
Parent weaknesses: CWE-668

Consequences:
  - Availability: DoS: Amplification

Mitigations:
  - [System Configuration] Assign IP addresses that are not 0.0.0.0.
  - [System Configuration] Unwanted connections to the configured server may be denied through a firewall or other packet filtering measures.

Demonstrative examples:
The following code snippet uses 0.0.0.0 in a Puppet script.
The Puppet code snippet is used to provision a signing server that will use 0.0.0.0 to accept traffic. However, as 0.0.0.0 is unrestricted, malicious users may use this IP address to launch frequent requests and cause denial of service attacks.
signingserver::instance { 
					 
					  "nightly-key-signing-server":
					   
					  listenaddr     => "0.0.0.0", 
					  port           => "9100", 
					  code_tag       => "SIGNING_SERVER", 
					   
					  }
signingserver::instance { 
					 
					  "nightly-key-signing-server":
					   
					  listenaddr     => "127.0.0.1", 
					  port           => "9100", 
					  code_tag       => "SIGNING_SERVER", 
					   
					  }

Real-world examples:
  - CVE-2023-41742: cybersecurity product binds to an unrestricted IP address
  - CVE-2022-21947: Desktop manager for Kubernetes and container management binds a service to 0.0.0.0, allowing users on the network to make requests to a dashboard API.
CWE-1328: Security Version Number Mutable to Older Versions

Description:
Security-version number in hardware is mutable, resulting in the ability to downgrade (roll-back) the boot firmware to vulnerable code versions.

Extended Description:
A System-on-Chip (SoC) implements secure boot or verified boot. It might support a security version number, which prevents downgrading the current firmware to a vulnerable version. Once downgraded to a previous version, an adversary can launch exploits on the SoC and thus compromise the security of the SoC. These downgrade attacks are also referred to as roll-back attacks. 
				 The security version number must be stored securely and persistently across power-on resets. A common weakness is that the security version number is modifiable by an adversary, allowing roll-back or downgrade attacks or, under certain circumstances, preventing upgrades (i.e. Denial-of-Service on upgrades). In both cases, the SoC is in a vulnerable state.

Affected languages: Not Language-Specific
Affected technologies: Security Hardware, Not Technology-Specific
Parent weaknesses: CWE-285

Consequences:
  - Confidentiality: Other

Detection methods:
  - Automated Dynamic Analysis: Mutability of stored security version numbers and programming with older firmware images should be part of automated testing.
  - Architecture or Design Review: Anti-roll-back features should be reviewed as part of Architecture or Design review.

Mitigations:
  - [Architecture and Design] When architecting the system, security version data should be designated for storage in registers that are either read-only or have access controls that prevent modification by an untrusted agent.
  - [Implementation] During implementation and test, security version data should be demonstrated to be read-only and access controls should be validated.

Demonstrative examples:
A new version of firmware is signed with a security version number higher than the previous version. During the firmware update process the SoC checks for the security version number and upgrades the SoC firmware with the latest version. This security version number is stored in persistent memory upon successful upgrade for use across power-on resets.
In general, if the security version number is mutable, the implementation is vulnerable. A mutable security version number allows an adversary to change the security version to a lower value to allow roll-back or to a higher value to prevent future upgrades.
CWE-1330: Remanent Data Readable after Memory Erase

Description:
Confidential information stored in memory circuits is readable or recoverable after being cleared or erased.

Extended Description:
Data remanence occurs when stored, memory content is not fully lost after a memory-clear or -erase operation. Confidential memory contents can still be readable through data remanence in the hardware. 
				 Data remanence can occur because of performance optimization or memory organization during 'clear' or 'erase' operations, like a design that allows the memory-organization metadata (e.g., file pointers) to be erased without erasing the actual memory content. To protect against this weakness, memory devices will often support different commands for optimized memory erase and explicit secure erase. 
				 Data remanence can also happen because of the physical properties of memory circuits in use. For example, static, random-access-memory (SRAM) and dynamic, random-access-memory (DRAM) data retention is based on the charge retained in the memory cell, which depends on factors such as power supply, refresh rates, and temperature. 
				 Other than explicit erase commands, self-encrypting,

Affected languages: Not Language-Specific
Affected technologies: Security Hardware, Not Technology-Specific
Parent weaknesses: CWE-1301, CWE-1301

Consequences:
  - Confidentiality: Modify Memory

Detection methods:
  - Architecture or Design Review: Testing of memory-device contents after clearing or erase commands. 
					 Dynamic analysis of memory contents during device operation to detect specific, confidential assets. 
					 Architecture and 
  - Dynamic Analysis with Manual Results Interpretation: Testing of memory-device contents after clearing or erase commands. 
					 Dynamic analysis of memory contents during device operation to detect specific, confidential assets. 
					 Architecture and 

Mitigations:
  - [Architecture and Design] Support for secure-erase commands that apply multiple cycles of overwriting memory with known patterns and of erasing actual content. 
					 Support for cryptographic erase in self-encrypting, memory devices. 
					 External, physical tools to erase memory such as ultraviolet-rays-based erase of Ele

Demonstrative examples:
Consider a device that uses flash memory for non-volatile-data storage. To optimize flash-access performance or reliable-flash lifetime, the device might limit the number of flash writes/erases by maintaining some state in internal SRAM and only committing changes to flash memory periodically.
The device also supports user reset to factory defaults with the expectation that all personal information is erased from the device after this operation. On factory reset, user files are erased using explicit, erase commands supported by the flash device.

Real-world examples:
  - CVE-2019-8575: Firmware Data Deletion Vulnerability in which a base station factory reset might not delete all user information. The impact of this enables a new owner of a used device that has been "factory-default
CWE-1331: Improper Isolation of Shared Resources in Network On Chip (NoC)

Description:
The Network On Chip (NoC) does not isolate or incorrectly isolates its on-chip-fabric and internal resources such that they are shared between trusted and untrusted agents, creating timing channels.

Extended Description:
Typically, network on chips (NoC) have many internal resources that are shared between packets from different trust domains. These resources include internal buffers, crossbars and switches, individual ports, and channels. The sharing of resources causes contention and introduces interference between differently trusted domains, which poses a security threat via a timing channel, allowing attackers to infer data that belongs to a trusted agent. This may also result in introducing network interference, resulting in degraded throughput and latency.

Affected languages: Not Language-Specific
Affected technologies: Security Hardware, Not Technology-Specific
Parent weaknesses: CWE-653, CWE-668

Consequences:
  - Confidentiality: DoS: Resource Consumption (Other)

Detection methods:
  - Manual Analysis: Providing marker flags to send through the interfaces coupled with examination of which users are able to read or manipulate the flags will help verify that the proper isolation has been achieved and 

Mitigations:
  - [Architecture and Design] Implement priority-based arbitration inside the NoC and have dedicated buffers or virtual channels for routing secret data from trusted agents.

Demonstrative examples:
Consider a NoC that implements a one-dimensional mesh network with four nodes. This supports two flows: Flow A from node 0 to node 3 (via node 1 and node 2) and Flow B from node 1 to node 2. Flows A and B share a common link between Node 1 and Node 2.  Only one flow can use the link in each cycle.
One of the masters to this NoC implements a cryptographic algorithm (RSA), and another master to the NoC is a core that can be exercised by an attacker. The RSA algorithm performs a modulo multiplication of two large numbers and depends on each bit of the secret key. The algorithm examines each bit in the secret key and only performs multiplication if the bit is 1. This algorithm is known to be prone to timing attacks. Whenever RSA performs multiplication, there is additional network traffic to t

Real-world examples:
  - CVE-2021-33096: Improper isolation of shared resource in a network-on-chip leads to denial of service
CWE-1334: Unauthorized Error Injection Can Degrade Hardware Redundancy

Description:
An unauthorized agent can inject errors into a redundant block to deprive the system of redundancy or put the system in a degraded operating mode.

Extended Description:
To ensure the performance and functional reliability of certain components, hardware designers can implement hardware blocks for redundancy in the case that others fail. This redundant block can be prevented from performing as intended if the design allows unauthorized agents to inject errors into it. In this way, a path with injected errors may become unavailable to serve as a redundant channel. This may put the system into a degraded mode of operation which could be exploited by a subsequent attack.

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

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

Mitigations:
  - [Architecture and Design] Ensure the design does not allow error injection in modes intended for normal run-time operation. Provide access controls on interfaces for injecting errors.
  - [Implementation] Disallow error injection in modes which are expected to be used for normal run-time operation. Provide access controls on interfaces for injecting errors.
  - [Integration] Add an access control layer atop any unprotected interfaces for injecting errors.