{"@ID": "1234", "@Name": "Hardware Internal or Debug Modes Allow Override of Locks", "@Abstraction": "Base", "@Structure": "Simple", "@Status": "Incomplete", "Description": "System configuration protection may be bypassed during debug mode.", "Extended_Description": {"xhtml:p": "Device configuration controls are commonly programmed after a device power reset by a trusted firmware or software module (e.g., BIOS/bootloader) and then locked from any further modification. This is commonly implemented using a trusted lock bit, which when set, disables writes to a protected set of registers or address regions. The lock protection is intended to prevent modification of certain system configuration (e.g., memory/memory protection unit configuration). If debug features supported by hardware or internal modes/system states are supported in the hardware design, modification of the lock protection may be allowed allowing access and modification of configuration information."}, "Related_Weaknesses": {"Related_Weakness": {"@Nature": "ChildOf", "@CWE_ID": "667", "@View_ID": "1000", "@Ordinal": "Primary"}}, "Weakness_Ordinalities": {"Weakness_Ordinality": {"Ordinality": "Primary"}}, "Applicable_Platforms": {"Language": {"@Class": "Not Language-Specific", "@Prevalence": "Undetermined"}, "Operating_System": {"@Class": "Not OS-Specific", "@Prevalence": "Undetermined"}, "Architecture": {"@Class": "Not Architecture-Specific", "@Prevalence": "Undetermined"}, "Technology": {"@Class": "Not Technology-Specific", "@Prevalence": "Undetermined"}}, "Modes_Of_Introduction": {"Introduction": [{"Phase": "Architecture and Design"}, {"Phase": "Implementation"}]}, "Common_Consequences": {"Consequence": {"Scope": "Access Control", "Impact": "Bypass Protection Mechanism", "Likelihood": "High", "Note": "Bypass of lock bit allows access and modification of system configuration even when the lock bit is set."}}, "Potential_Mitigations": {"Mitigation": {"Phase": ["Architecture and Design", "Implementation", "Testing"], "Description": {"xhtml:ul": {"xhtml:li": ["Security Lock bit protections should be reviewed for any bypass/override modes supported.", "Any supported override modes either should be removed or protected using authenticated debug modes.", "Security lock programming flow and lock properties should be tested in pre-silicon and post-silicon testing."]}}, "Effectiveness": "High"}}, "Demonstrative_Examples": {"Demonstrative_Example": [{"Intro_Text": {"xhtml:br": null, "#text": "For example, consider the example Locked_override_register example. This register module supports a lock mode that blocks any writes after lock is set to 1.\n        \n         However, it also allows override of the lock protection when scan_mode or debug_unlocked modes are active."}, "Example_Code": [{"@Nature": "Bad", "@Language": "Verilog", "xhtml:br": [null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null, null], "xhtml:div": [{"@style": "margin-left:1em;", "xhtml:br": [null, null, null, null, null, null, null, null, null], "xhtml:div": [{"@style": "margin-left:1em;", "xhtml:br": null, "#text": "lock_status <= 1'b0;"}, {"@style": "margin-left:1em;", "xhtml:br": null, "#text": "lock_status <= 1'b1;"}, {"@style": "margin-left:1em;", "xhtml:br": null, "#text": "lock_status <= lock_status"}], "#text": "if (~resetn) // Register is reset resetn\n\t\t\tbegin\n\t\t\t\n\t\t\tend\n\t\t\telse if (Lock)\n\t\t\tbegin\n\t\t\t\n\t\t\tend\n\t\t\telse if (~Lock)\n\t\t\tbegin\n\t\t\t\n\t\t\tend"}, {"@style": "margin-left:1em;", "xhtml:br": [null, null, null, null, null, null, null, null, null], "xhtml:div": [{"@style": "margin-left:1em;", "xhtml:br": null, "#text": "Data_out <= 16'h0000;"}, {"@style": "margin-left:1em;", "xhtml:br": null, "#text": "Data_out <= Data_in;"}, {"@style": "margin-left:1em;", "xhtml:br": null, "#text": "Data_out <= Data_out;"}], "#text": "if (~resetn) // Register is reset resetn\n\t\t\tbegin\n\t\t\t\n\t\t\tend\n\t\t\telse if (write & (~lock_status | scan_mode | debug_unlocked) ) // Register protected by Lock bit input, overrides supported for scan_mode & debug_unlocked\n\t\t\tbegin\n\t\t\t\n\t\t\tend\n\t\t\telse if (~write)\n\t\t\tbegin\n\t\t\t\n\t\t\tend"}], "#text": "module Locked_register_example\n          (\n\t\t  input [15:0] Data_in,\n\t\t  input Clk,\n\t\t  input resetn,\n\t\t  input write,\n\t\t  input Lock,\n\t\t  input scan_mode,\n\t\t  input debug_unlocked,\n\t\t  output reg [15:0] Data_out\n\t\t  );\n          \n          reg lock_status;\n          \n          always @(posedge Clk or negedge resetn)\n\t\t  \n\t\t  always @(posedge Clk or negedge resetn)\n\t\t  \n\t\t  endmodule"}, {"@Nature": "Good", "@Language": "Other", "#text": "Either remove the debug and scan mode overrides or protect enabling of these modes so that only trusted and authorized users may enable these modes."}], "Body_Text": "If either the scan_mode or the debug_unlocked modes can be triggered by software, then the lock protection may be bypassed."}, {"Intro_Text": "The following example code [REF-1375] is taken from the register lock security peripheral of the HACK@DAC'21 buggy OpenPiton SoC. It demonstrates how to lock read or write access to security-critical hardware registers (e.g., crypto keys, system integrity code, etc.). The configuration to lock all the sensitive registers in the SoC is managed through the reglk_mem registers. These reglk_mem registers are reset when the hardware powers up and configured during boot up. Malicious users, even with kernel-level software privilege, do not get access to the sensitive contents that are locked down. Hence, the security of the entire system can potentially be compromised if the register lock configurations are corrupted or if the register locks are disabled.", "Example_Code": [{"@Nature": "Bad", "@Language": "Verilog", "xhtml:br": [null, null, null], "xhtml:div": {"@style": "margin-left:1em;", "xhtml:br": null, "xhtml:div": {"@style": "margin-left:1em;", "xhtml:b": "if(~(rst_ni && ~jtag_unlock && ~rst_9))", "xhtml:br": null, "xhtml:div": {"@style": "margin-left:1em;", "xhtml:br": [null, null], "xhtml:div": {"@style": "margin-left:1em;", "xhtml:br": [null, null], "xhtml:div": {"@style": "margin-left:1em;", "xhtml:br": null, "#text": "reglk_mem[j] <= 'h0;"}, "#text": "for (j=0; j < 6; j=j+1) begin\n\t\t\t\t\t\t\t\n\t\t\t\t\t\tend"}, "#text": "begin\n\t\t\t\t\t\t\n\t\t\t\t\tend"}}, "#text": "begin"}, "#text": "...\n\t\talways @(posedge clk_i)\n\t\t\t\n\t\t..."}, {"@Nature": "Good", "@Language": "Verilog", "xhtml:br": [null, null, null], "xhtml:div": {"@style": "margin-left:1em;", "xhtml:br": null, "xhtml:div": {"@style": "margin-left:1em;", "xhtml:b": "if(~(rst_ni && ~rst_9))", "xhtml:br": null, "xhtml:div": {"@style": "margin-left:1em;", "xhtml:br": [null, null], "xhtml:div": {"@style": "margin-left:1em;", "xhtml:br": [null, null], "xhtml:div": {"@style": "margin-left:1em;", "xhtml:br": null, "#text": "reglk_mem[j] <= 'h0;"}, "#text": "for (j=0; j < 6; j=j+1) begin\n\t\t\t\t\t\t\t\n\t\t\t\t\t\tend"}, "#text": "begin\n\t\t\t\t\t\t\n\t\t\t\t\tend"}}, "#text": "begin"}, "#text": "...\n\t\talways @(posedge clk_i)\n\t\t\t\n\t\t..."}], "Body_Text": ["The example code [REF-1375] illustrates an instance of a vulnerable implementation of register locks in the SoC. In this flawed implementation [REF-1375], the reglk_mem registers are also being reset when the system enters debug mode (indicated by the jtag_unlock signal). Consequently, users can simply put the processor in debug mode to access sensitive contents that are supposed to be protected by the register lock feature.", "This can be mitigated by excluding debug mode signals from the reset logic of security-critical register locks as demonstrated in the following code snippet [REF-1376]."]}]}, "Related_Attack_Patterns": {"Related_Attack_Pattern": {"@CAPEC_ID": "176"}}, "References": {"Reference": [{"@External_Reference_ID": "REF-1375"}, {"@External_Reference_ID": "REF-1376"}]}, "Mapping_Notes": {"Usage": "Allowed", "Rationale": "This CWE entry is at the Base 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.", "Reasons": {"Reason": {"@Type": "Acceptable-Use"}}}, "Content_History": {"Submission": {"Submission_Name": "Arun Kanuparthi, Hareesh Khattri, Parbati Kumar Manna, Narasimha Kumar V Mangipudi", "Submission_Organization": "Intel Corporation", "Submission_Date": "2020-01-15", "Submission_Version": "4.0", "Submission_ReleaseDate": "2020-02-24"}, "Modification": [{"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2020-08-20", "Modification_Version": "4.2", "Modification_ReleaseDate": "2020-08-20", "Modification_Comment": "updated Common_Consequences, Demonstrative_Examples, Description, Modes_of_Introduction, Potential_Mitigations, Related_Attack_Patterns"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2022-04-28", "Modification_Version": "4.7", "Modification_ReleaseDate": "2022-04-28", "Modification_Comment": "updated Related_Attack_Patterns"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2022-10-13", "Modification_Version": "4.9", "Modification_ReleaseDate": "2022-10-13", "Modification_Comment": "updated Demonstrative_Examples"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2023-04-27", "Modification_Version": "4.11", "Modification_ReleaseDate": "2023-04-27", "Modification_Comment": "updated Relationships"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2023-06-29", "Modification_Version": "4.12", "Modification_ReleaseDate": "2023-06-29", "Modification_Comment": "updated Mapping_Notes"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2024-02-29", "Modification_Version": "4.14", "Modification_ReleaseDate": "2024-02-29", "Modification_Comment": "updated Demonstrative_Examples, References"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2025-09-09", "Modification_Version": "4.18", "Modification_ReleaseDate": "2025-09-09", "Modification_Comment": "updated Relationships"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2025-12-11", "Modification_Version": "4.19", "Modification_ReleaseDate": "2025-12-11", "Modification_Comment": "updated Demonstrative_Examples, Weakness_Ordinalities"}], "Contribution": [{"@Type": "Content", "Contribution_Name": "Chen Chen, Rahul Kande, Jeyavijayan Rajendran", "Contribution_Organization": "Texas A&M University", "Contribution_Date": "2023-11-07", "Contribution_Comment": "suggested demonstrative example"}, {"@Type": "Content", "Contribution_Name": "Shaza Zeitouni, Mohamadreza Rostami, Ahmad-Reza Sadeghi", "Contribution_Organization": "Technical University of Darmstadt", "Contribution_Date": "2023-11-07", "Contribution_Comment": "suggested demonstrative example"}]}}