2023
Operating_System : Not OS-Specific (Prevalence = Undetermined)
Architecture : Not Architecture-Specific (Prevalence = Undetermined)
Technology : System on Chip (Prevalence = Undetermined)
Common Consequences
Scope Impact Likelihood
Confidentiality 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.
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.
Example Language: Verilog (Bad)
...
// 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
CWE Version 4.14
CWE-1239: Improper Zeroization of Hardware Register
CWE-1239: Improper Zeroization of Hardware Register