CWE

Common Weakness Enumeration

A community-developed list of SW & HW weaknesses that can become vulnerabilities
New to CWE? click here!
CWE Most Important Hardware Weaknesses
CWE Top 25 Most Dangerous Weaknesses
Home > CWE List > CWE-1239: Improper Zeroization of Hardware Register (4.16)  
ID

CWE-1239: Improper Zeroization of Hardware Register

Weakness ID: 1239
Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction: Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.
View customized information:
For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.
×

Edit Custom Filter


+ 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].
+ Common Consequences
Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Scope Impact Likelihood
Confidentiality

Technical Impact: Varies by Context

The consequences will depend on the information disclosed due to the vulnerability.
+ Potential Mitigations

Phase: 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.
Note: Unfortunately, data disclosure can occur even after information has been overwritten/zeroized from the digital perspective. Physical characteristics of the memory can reveal the history of previously written data. For example, if the same value is written repeatedly to a memory location, the corresponding memory cells can become physically altered to a degree that even if the original data is erased it can still be recovered through physical characterization of the memory cells [REF-1055].
+ Relationships
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name
ChildOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 226 Sensitive Information in Resource Not Removed Before Reuse
Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
+ Relevant to the view "Hardware Design" (CWE-1194)
Nature Type ID Name
ChildOf Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource. 226 Sensitive Information in Resource Not Removed Before Reuse
+ Modes Of Introduction
Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Phase Note
Architecture and Design Lack of hardware mechanisms to zeroize or clear registers in the design or specification.
Implementation Mechanisms to zeroize and clear registers are in the design but implemented incorrectly.
Operation Hardware-provided zeroization mechanisms are not used appropriately by the IP user (ex. firmware), or data remanence issues are not taken into account.
+ Applicable Platforms
Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Operating Systems

Class: Not OS-Specific (Undetermined Prevalence)

Architectures

Class: Not Architecture-Specific (Undetermined Prevalence)

Technologies

Class: System on Chip (Undetermined Prevalence)

+ Demonstrative Examples

Example 1

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.


Example 2

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.

(bad code)
Example Language: Verilog 
...
// Implement SHA256 I/O memory map interface
// Write side
always @(posedge clk_i)
begin
if(~(rst_ni && ~rst_3))
begin
startHash <= 0;
newMessage <= 0;
data[0] <= 0;
data[1] <= 0;
data[2] <= 0;
...
data[14] <= 0;
data[15] <= 0;
...

In the previous code snippet [REF-1379] there is the lack of a data clearance mechanism for the memory-mapped I/O registers after their utilization. These registers get cleared only when a reset condition is met. This condition is met when either the global negative-edge reset input signal (rst_ni) or the dedicated reset input signal for SHA256 peripheral (rst_3) is active. In other words, if either of these reset signals is true, the registers will be cleared. However, in cases where there is not a reset condition these registers retain their values until the next hash operation. It is during the time between an old hash operation and a new hash operation that that data is open to unauthorized disclosure.

To correct the issue of data persisting between hash operations, the memory mapped I/O registers need to be cleared once the values written in these registers are propagated to the SHA256 module. This could be done for example by adding a new condition to zeroize the memory mapped I/O registers once the hash value is computed, i.e., hashValid signal asserted, as shown in the good code example below [REF-1380]. This fix will clear the memory-mapped I/O registers after the data has been provided as input to the SHA engine.

(good code)
Example Language: Verilog 
...
// Implement SHA256 I/O memory map interface
// Write side
always @(posedge clk_i)
begin
if(~(rst_ni && ~rst_3))
begin
startHash <= 0;
newMessage <= 0;
data[0] <= 0;
data[1] <= 0;
data[2] <= 0;
...
data[14] <= 0;
data[15] <= 0;
end
else if(hashValid && ~hashValid_r)
begin
data[0] <= 0;
data[1] <= 0;
data[2] <= 0;
...
data[14] <= 0;
data[15] <= 0;
end
...

+ Memberships
Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Nature Type ID Name
MemberOf CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic. 1416 Comprehensive Categorization: Resource Lifecycle Management
+ Vulnerability Mapping Notes

Usage: ALLOWED

(this CWE ID may be used to map to real-world vulnerabilities)

Reason: Acceptable-Use

Rationale:

This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.

Comments:

Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
+ References
[REF-267] Information Technology Laboratory, National Institute of Standards and Technology. "SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES". 2001-05-25. <https://csrc.nist.gov/csrc/media/publications/fips/140/2/final/documents/fips1402.pdf>. URL validated: 2023-04-07.
[REF-1055] Peter Gutmann. "Data Remanence in Semiconductor Devices". 10th USENIX Security Symposium. 2001-08. <https://www.usenix.org/legacy/events/sec01/full_papers/gutmann/gutmann.pdf>.
+ Content History
+ Submissions
Submission Date Submitter Organization
2020-02-08
(CWE 4.0, 2020-02-24) 		Nicole Fern Cycuity (originally submitted as Tortuga Logic)
+ Contributions
Contribution Date Contributor Organization
2023-11-07 Chen Chen, Rahul Kande, Jeyavijayan Rajendran Texas A&M University
suggested demonstrative example
2023-11-07 Shaza Zeitouni, Mohamadreza Rostami, Ahmad-Reza Sadeghi Technical University of Darmstadt
suggested demonstrative example
+ Modifications
Modification Date Modifier Organization
2020-08-20 CWE Content Team MITRE
updated Related_Attack_Patterns
2021-10-28 CWE Content Team MITRE
updated Relationships
2023-04-27 CWE Content Team MITRE
updated References, Relationships
2023-06-29 CWE Content Team MITRE
updated Mapping_Notes
2024-02-29
(CWE 4.14, 2024-02-29) 		CWE Content Team MITRE
updated Demonstrative_Examples, References
Page Last Updated: November 19, 2024
 

Use of the Common Weakness Enumeration (CWE™) and the associated references from this website are subject to the Terms of Use. CWE is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE). Copyright © 2006–2024, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation.