deardaniel/secdata-raw huggingface dataset:
CWE-1292: Incorrect Conversion of Security Identifiers

Description:
The product implements a conversion mechanism to map certain bus-transaction signals to security identifiers. However, if the conversion is incorrectly implemented, untrusted agents can gain unauthorized access to the asset.

Extended Description:
In a System-On-Chip (SoC), various integrated circuits and hardware engines generate transactions such as to access (reads/writes) assets or perform certain actions (e.g., reset, fetch, compute, etc.). Among various types of message information, a typical transaction is comprised of source identity (to identify the originator of the transaction) and a destination identity (to route the transaction to the respective entity). Sometimes the transactions are qualified with a security identifier. This security identifier helps the destination agent decide on the set of allowed actions (e.g., access an asset for read and writes). 
				 A typical bus connects several leader and follower agents. Some follower agents implement bus protocols differently from leader agents. A protocol conversion happens at a bridge to seamlessly connect different protocols on the bus. One example is a system that implements a leader with the Advanced High-performance Bus (AHB) protocol and a follower with the Ope

Affected languages: Not Language-Specific
Affected technologies: Bus/Interface Hardware, Not Technology-Specific
Parent weaknesses: CWE-284, CWE-1294

Consequences:
  - Confidentiality: Modify Memory

Mitigations:
  - [Architecture and Design] Security identifier decoders must be reviewed for design inconsistency and common weaknesses.
  - [Implementation] Access and programming flows must be tested in pre-silicon and post-silicon testing.

Demonstrative examples:
Consider a system that supports AHB. Let us assume we have a follower agent that only understands OCP. To connect this follower to the leader, a bridge is introduced, i.e., AHB to OCP.
                         
                         
                            The follower has assets to protect accesses from untrusted leaders, and it employs access controls based on policy, (e.g., AES-Key registers for encryption or decryption). The key is 128 bits implemented as a set of four 32-bit registers. The key registers are assets, and register AES_KEY_ACCESS_POLICY is defined to provide the necessary access controls. 
                         
                         
                            The AES_KEY_ACCESS_POLICY access-policy register defines which agents with a security identifier
CWE-1293: Missing Source Correlation of Multiple Independent Data

Description:
The product relies on one source of data, preventing the ability to detect if an adversary has compromised a data source.

Extended Description:
To operate successfully, a product sometimes has to implicitly trust the integrity of an information source. When information is implicitly signed, one can ensure that the data was not tampered in transit. This does not ensure that the information source was not compromised when responding to a request. By requesting information from multiple sources, one can check if all of the data is the same. If they are not, the system should report the information sources that respond with a different or minority value as potentially compromised. If there are not enough answers to provide a majority or plurality of responses, the system should report all of the sources as potentially compromised. As the seriousness of the impact of incorrect integrity increases, so should the number of independent information sources that would need to be queried.

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

Consequences:
  - Confidentiality: Read Application Data

Mitigations:
  - [Requirements] Design system to use a Practical Byzantine fault method, to request information from multiple sources to verify the data and report on potentially compromised information sources.
  - [Implementation] Failure to use a Practical Byzantine fault method when requesting data. Lack of place to report potentially compromised information sources. Relying on non-independent information sources for integrity checking. Failure to report information sources that respond in the minority to incident response
CWE-1294: Insecure Security Identifier Mechanism

Description:
The System-on-Chip (SoC) implements a Security Identifier mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. However, the Security Identifiers are not correctly implemented.

Extended Description:
Systems-On-Chip (Integrated circuits and hardware
                    engines) implement Security Identifiers to
                    differentiate/identify actions originated from various
                    agents. These actions could be 'read', 'write', 'program',
                    'reset', 'fetch', 'compute', etc. Security identifiers are
                    generated and assigned to every agent in the System (SoC)
                    that is either capable of generating an action or receiving
                    an action from another agent. Every agent could be assigned
                    a unique, Security Identifier based on its trust level or
                    privileges. 
                 A broad class of flaws can exist in the Security
                    Identifier process, including but not limited to missing
                    security identifiers, improper conversion of security
                    identifiers, incorrect generation of security identifiers,
         

Affected languages: Not Language-Specific
Affected technologies: Bus/Interface Hardware, Not Technology-Specific
Parent weaknesses: CWE-284

Consequences:
  - Confidentiality: Modify Memory

Mitigations:
  - [Architecture and Design] Security Identifier Decoders must be reviewed for design inconsistency and common weaknesses.
  - [Implementation] Access and programming flows must be tested in pre-silicon and post-silicon testing.
CWE-1295: Debug Messages Revealing Unnecessary Information

Description:
The product fails to adequately prevent the revealing of unnecessary and potentially sensitive system information within debugging messages.

Extended Description:
Debug messages are messages that help troubleshoot an issue by revealing the internal state of the system. For example, debug data in design can be exposed through internal memory array dumps or boot logs through interfaces like UART via TAP commands, scan chain, etc. Thus, the more information contained in a debug message, the easier it is to debug. However, there is also the risk of revealing information that could help an attacker either decipher a vulnerability, and/or gain a better understanding of the system. Thus, this extra information could lower the "security by obscurity" factor. While "security by obscurity" alone is insufficient, it can help as a part of "Defense-in-depth".

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

Consequences:
  - Confidentiality: Read Memory

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] Ensure that a debug message does not reveal any unnecessary information during the debug process for the intended response.

Demonstrative examples:
This example here shows how an attacker can take advantage of unnecessary information in debug messages.
Example 1: Suppose in response to a Test Access Port (TAP) chaining request the debug message also reveals the current TAP hierarchy (the full topology) in addition to the success/failure message.

Real-world examples:
  - CVE-2022-34364: Java-based SDK for TLS has a debug message with unnecessary information
  - CVE-2021-25476: Digital Rights Management (DRM) capability for mobile platform leaks pointer information, simplifying ASLR bypass
  - CVE-2020-24491: Processor generates debug message that contains sensitive information ("addresses of memory transactions").
  - CVE-2017-18326: modem debug messages include cryptographic keys
CWE-1296: Incorrect Chaining or Granularity of Debug Components

Description:
The product's debug components contain incorrect chaining or granularity of debug components.

Extended Description:
For debugging and troubleshooting a chip, several hardware design elements are often implemented, including: 
				 
				 Various Test Access Ports (TAPs) allow boundary scan commands to be executed. 
				 For scanning the internal components of a chip, there are scan cells that allow the chip to be used as a "stimulus and response" mechanism. 
				 Chipmakers might create custom methods to observe the internal components of their chips by placing various tracing hubs within their chip and creating hierarchical or interconnected structures among those hubs. 
				 
				 Logic errors during design or synthesis could misconfigure the interconnection of the debug components, which could allow unintended access permissions.

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

Consequences:
  - Confidentiality: Gain Privileges or Assume Identity

Detection methods:
  - Architecture or Design Review: Appropriate Post-Si tests should be carried out at various authorization levels to ensure that debug components are properly chained and accessible only to users with appropriate credentials.
  - Dynamic Analysis with Manual Results Interpretation: Appropriate Post-Si tests should be carried out at various authorization levels to ensure that debug components are properly chained and accessible only to users with appropriate credentials.

Mitigations:
  - [Implementation] Ensure that debug components are properly chained and their granularity is maintained at different authentication levels.

Demonstrative examples:
The following example shows how an attacker can take advantage of incorrect chaining or missing granularity of debug components.
In a System-on-Chip (SoC), the user might be able to access the SoC-level TAP with a certain level of authorization. However, this access should not also grant access to all of the internal TAPs (e.g., Core). Separately, if any of the internal TAPs is also stitched to the TAP chain when it should not be because of a logic error, then an attacker can access the internal TAPs as well and execute commands there.

Real-world examples:
  - CVE-2017-18347: Incorrect access control in RDP Level 1 on STMicroelectronics STM32F0 series devices allows physically present attackers to extract the device's protected firmware via a special sequence of Serial Wir
  - CVE-2020-1791: There is an improper authorization vulnerability in several smartphones.  The system has a logic-judging error, and, under certain scenarios, a successful exploit could allow the attacker to switch to
CWE-1297: Unprotected Confidential Information on Device is Accessible by OSAT Vendors

Description:
The product does not adequately protect confidential information on the device from being accessed by Outsourced Semiconductor Assembly and Test (OSAT) vendors.

Extended Description:
In contrast to complete vertical integration of architecting, designing, manufacturing, assembling, and testing chips all within a single organization, an organization can choose to simply architect and design a chip before outsourcing the rest of the process to OSAT entities (e.g., external foundries and test houses). In the latter example, the device enters an OSAT facility in a much more vulnerable pre-production stage where many debug and test modes are accessible. Therefore, the chipmaker must place a certain level of trust with the OSAT. To counter this, the chipmaker often requires the OSAT partner to enter into restrictive non-disclosure agreements (NDAs). Nonetheless, OSAT vendors likely have many customers, which increases the risk of accidental sharing of information. There may also be a security vulnerability in the information technology (IT) system of the OSAT facility. Alternatively, a malicious insider at the OSAT facility may carry out an insider attack. Considering th

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

Consequences:
  - Confidentiality: Gain Privileges or Assume Identity

Detection methods:
  - Architecture or Design Review: Appropriate Post-Si tests should be carried out to ensure that residual confidential information is not left on parts leaving one facility for another facility.
  - Dynamic Analysis with Manual Results Interpretation: Appropriate Post-Si tests should be carried out to ensure that residual confidential information is not left on parts leaving one facility for another facility.

Mitigations:
  - [Architecture and Design] Ensure that when an OSAT vendor is allowed to access test interfaces necessary for preproduction and returned parts, the vendor only pulls the minimal information necessary. Also, architect the product in such a way that, when an "unlock device" request comes, it only unlocks that specific part and 

Demonstrative examples:
The following example shows how an attacker can take advantage of a piece of confidential information that has not been protected from the OSAT.
Suppose the preproduction device contains NVM (a storage medium that by definition/design can retain its data without power), and this NVM contains a key that can unlock all the parts for that generation.  An OSAT facility accidentally leaks the key.
CWE-1298: Hardware Logic Contains Race Conditions

Description:
A race condition in the hardware logic results in undermining security guarantees of the system.

Extended Description:
A race condition in logic circuits typically occurs when a logic gate gets inputs from signals that have traversed different paths while originating from the same source. Such inputs to the gate can change at slightly different times in response to a change in the source signal. This results in a timing error or a glitch (temporary or permanent) that causes the output to change to an unwanted state before settling back to the desired state. If such timing errors occur in access control logic or finite state machines that are implemented in security sensitive flows, an attacker might exploit them to circumvent existing protections.

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

Consequences:
  - Access Control: Bypass Protection Mechanism

Mitigations:
  - [Architecture and Design] Adopting design practices that encourage designers to recognize and eliminate race conditions, such as Karnaugh maps, could result in the decrease in occurrences of race conditions.
  - [Implementation] Logic redundancy can be implemented along security critical paths to prevent race conditions. To avoid metastability, it is a good practice in general to default to a secure state in which access is not given to untrusted agents.

Demonstrative examples:
The code below shows a 2x1 multiplexor using logic gates. Though the code shown below results in the minimum gate solution, it is disjoint and causes glitches.
The buggy line of code, commented above, results in signal 'z' periodically changing to an unwanted state. Thus, any logic that references signal 'z' may access it at a time when it is in this unwanted state. This line should be replaced with the line shown below in the Good Code Snippet which results in signal 'z' remaining in a continuous, known, state. Reference for the above code, along with waveforms for simulation can be found in the references below.
// 2x1 Multiplexor using logic-gates 
                         
						module glitchEx( 
						 
							input wire in0, in1, sel, 
							output wire z 
						 
						); 
        

The example code is taken from the DMA (Direct Memory Access) module of the buggy OpenPiton SoC of HACK@DAC'21. The DMA contains a finite-state machine (FSM) for accessing the permissions using the physical memory protection (PMP) unit. 
					 PMP provides secure regions of physical memory against unauthorized access. It allows an operating system or a hypervisor to define a series of physical memory regions and then set permissions for those regions, such as read, write, and execute permissions. When a user tries to access a protected memory area (e.g., through DMA), PMP checks the access of a PMP address (e.g., pmpaddr_i) against its configuration (pmpcfg_i). If the access violates the defined permissions (e.g., CTRL_ABORT), the PMP can trigger a fault or an interrupt. This access check
CWE-13: ASP.NET Misconfiguration: Password in Configuration File

Description:
Storing a plaintext password in a configuration file allows anyone who can read the file access to the password-protected resource making them an easy target for attackers.

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

Consequences:
  - Access Control: Gain Privileges or Assume Identity

Mitigations:
  - [Implementation] Credentials stored in configuration files should be encrypted, Use standard APIs and industry accepted algorithms to encrypt the credentials stored in configuration files.

Demonstrative examples:
The following example shows a portion of a configuration file for an ASP.Net application. This configuration file includes username and password information for a connection to a database, but the pair is stored in plaintext.
Username and password information should not be included in a configuration file or a properties file in plaintext as this will allow anyone who can read the file access to the resource. If possible, encrypt this information.
... <connectionStrings> <add name="ud_DEV" connectionString="connectDB=uDB; uid=db2admin; [CREDENTIAL_REDACTED]; dbalias=uDB;" providerName="System.Data.Odbc" /> </connectionStrings> ...
CWE-1301: Insufficient or Incomplete Data Removal within Hardware Component

Description:
The product's data removal process does not completely delete all data and potentially sensitive information within hardware components.

Extended Description:
Physical properties of hardware devices, such as remanence of magnetic media, residual charge of ROMs/RAMs, or screen burn-in may still retain sensitive data after a data removal process has taken place and power is removed. 
				 Recovering data after erasure or overwriting is possible due to a phenomenon called data remanence. For example, if the same value is written repeatedly to a memory location, the corresponding memory cells can become physically altered to a degree such that even after the original data is erased that data can still be recovered through physical characterization of the memory cells.

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

Consequences:
  - Confidentiality: Read Memory

Mitigations:
  - [Architecture and Design] Apply blinding or masking techniques to implementations of cryptographic algorithms.
  - [Implementation] Alter the method of erasure, add protection of media, or destroy the media to protect the data.

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-1302: Missing Source Identifier in Entity Transactions on a System-On-Chip (SOC)

Description:
The product implements a security identifier mechanism to differentiate what actions are allowed or disallowed when a transaction originates from an entity. A transaction is sent without a security identifier.

Extended Description:
In a System-On-Chip (SoC), various integrated circuits and hardware engines generate transactions such as to access (reads/writes) assets or perform certain actions (e.g., reset, fetch, compute). A typical transaction is comprised of source identity (to identify the originator of the transaction) and a destination identity (to route the transaction to the respective entity) in addition to much more information in the message. Sometimes the transactions are qualified with a Security Identifier.  This Security Identifier helps the destination agent decide on the set of allowed or disallowed actions. 
				 A weakness that can exist in such transaction schemes is that the source agent does not consistently include the necessary Security Identifier with the transaction.  If the Security Identifier is missing, the destination agent might drop the message (resulting in an inadvertent Denial-of-Service (DoS)) or take inappropriate action by default in its attempt to execute the transaction, re

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

Consequences:
  - Confidentiality: Modify Memory

Mitigations:
  - [Architecture and Design] Transaction details must be reviewed for design inconsistency and common weaknesses.
  - [Implementation] Security identifier definition and programming flow must be tested in pre-silicon and post-silicon testing.

Demonstrative examples:
Consider a system with a register for storing AES key for encryption or decryption. The key is of 128 bits implemented as a set of four 32-bit registers.  The key registers are assets, and the register AES_KEY_ACCESS_POLICY is defined to provide the necessary access controls. 
						 The access-policy register defines which agents with a security identifier in the transaction can access the AES-key registers. Each bit in this 32-bit register defines a security identifier. There could be a maximum of 32 security identifiers that are allowed accesses to the AES-key registers. The number of the bit when set (i.e., "1") allows for a respective action from an agent whose identity matches the number of the bit; if set to "0" (i.e., Clear), it disallows the respective action to that corresponding