Access Control Check Implemented After Asset is Accessed
This vulnerability occurs when a hardware-based security check runs after the protected resource has already been accessed, creating a dangerous timing window.
In secure systems, hardware-based access control (like memory or I/O protection) must be verified before any access is granted. This flaw breaks that fundamental rule by allowing the asset to be accessed first, with the permission check happening as a separate, non-atomic step. This creates a critical race condition where an attacker can exploit the gap between access and authorization. For developers, this means the security check is effectively bypassed because the system acts first and asks for permission later. To fix this, the access control verification must be made atomic with the access operation itself, ensuring the check is an inseparable gatekeeper that always completes successfully before any data or hardware resource is exposed.
Impact: Modify MemoryRead MemoryModify Application DataRead Application DataGain Privileges or Assume IdentityBypass Protection Mechanism
ID : DX-187
Assume that the module foo_bar implements a protected register. The register content is the asset. Only transactions made by user id (indicated by signal usr_id) 0x4 are allowed to modify the register contents. The signal grant_access is used to provide access.Code Example:
module foo_bar(data_out, usr_id, data_in, clk, rst_n); output reg [7:0] data_out; input wire [2:0] usr_id; input wire [7:0] data_in; input wire clk, rst_n; wire grant_access; always @ (posedge clk or negedge rst_n) begin
verilogCode Example:
always @ (posedge clk or negedge rst_n) begin
verilog