{"@ID": "1256", "@Name": "Improper Restriction of Software Interfaces to Hardware Features", "@Abstraction": "Base", "@Structure": "Simple", "@Status": "Stable", "Description": "The product provides software-controllable\n\t\t\tdevice functionality for capabilities such as power and\n\t\t\tclock management, but it does not properly limit\n\t\t\tfunctionality that can lead to modification of\n\t\t\thardware memory or register bits, or the ability to\n\t\t\tobserve physical side channels.", "Extended_Description": {"xhtml:p": ["It is frequently assumed that physical attacks\n              such as fault injection and side-channel analysis\n              require an attacker to have physical access to the\n              target device.  This assumption may be false if the\n              device has improperly secured power management features,\n              or similar features.  For mobile devices, minimizing\n              power consumption is critical, but these devices run a\n              wide variety of applications with different performance\n              requirements. Software-controllable mechanisms to\n              dynamically scale device voltage and frequency and\n              monitor power consumption are common features in today's\n              chipsets, but they also enable attackers to mount fault\n              injection and side-channel attacks without having\n              physical access to the device.", "Fault injection attacks involve strategic\n              manipulation of bits in a device to achieve a desired\n              effect such as skipping an authentication step,\n              elevating privileges, or altering the output of a\n              cryptographic operation.  Manipulation of the device\n              clock and voltage supply is a well-known technique to\n              inject faults and is cheap to implement with physical\n              device access.  Poorly protected power management\n              features allow these attacks to be performed from\n              software.  Other features, such as the ability to write\n              repeatedly to DRAM at a rapid rate from unprivileged\n              software, can result in bit flips in other memory\n              locations (Rowhammer, [REF-1083]).", "Side channel analysis requires gathering\n\t\t\t  measurement traces of physical quantities such as power\n\t\t\t  consumption.  Modern processors often include power\n\t\t\t  metering capabilities in the hardware itself (e.g.,\n\t\t\t  Intel RAPL) which if not adequately protected enable\n\t\t\t  attackers to gather measurements necessary for\n\t\t\t  performing side-channel attacks from software."]}, "Related_Weaknesses": {"Related_Weakness": {"@Nature": "ChildOf", "@CWE_ID": "285", "@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"}, {"@Name": "Memory Hardware", "@Prevalence": "Undetermined"}, {"@Name": "Power Management Hardware", "@Prevalence": "Undetermined"}, {"@Name": "Clock/Counter Hardware", "@Prevalence": "Undetermined"}]}, "Modes_Of_Introduction": {"Introduction": [{"Phase": "Architecture and Design", "Note": "An architect may initiate introduction of\n\t\t\t\t\tthis weakness via exacting requirements for\n\t\t\t\t\tsoftware accessible power/clock management\n\t\t\t\t\trequirements"}, {"Phase": "Implementation", "Note": "An implementer may introduce this weakness\n\t\t\t\t\tby assuming there are no consequences to unbounded\n\t\t\t\t\tpower and clock management for secure components\n\t\t\t\t\tfrom untrusted ones."}]}, "Common_Consequences": {"Consequence": {"Scope": "Integrity", "Impact": ["Modify Memory", "Modify Application Data", "Bypass Protection Mechanism"]}}, "Detection_Methods": {"Detection_Method": [{"Method": "Manual Analysis", "Description": "Perform a security evaluation of system-level\n\t\tarchitecture and design with software-aided physical attacks\n\t\tin scope."}, {"Method": "Automated Dynamic Analysis", "Description": {"xhtml:p": "Use custom software to change registers that control clock settings or power settings to try to bypass security locks, or repeatedly write DRAM to try to change adjacent locations. This can be effective in extracting or changing data. The drawback is that it cannot be run before manufacturing, and it may require specialized software."}, "Effectiveness": "Moderate"}]}, "Potential_Mitigations": {"Mitigation": {"Phase": ["Architecture and Design", "Implementation"], "Description": {"xhtml:p": "Ensure proper access control mechanisms protect software-controllable features altering physical operating conditions such as clock frequency and voltage."}}}, "Demonstrative_Examples": {"Demonstrative_Example": [{"Intro_Text": "This example considers the Rowhammer problem [REF-1083]. The Rowhammer issue was caused by a program in a tight loop writing repeatedly to a location to which the program was allowed to write but causing an adjacent memory location value to change.", "Example_Code": [{"@Nature": "Bad", "@Language": "Other", "#text": "Continuously writing the same value to the same address causes the value of an adjacent location to change value."}, {"@Nature": "Good", "@Language": "Other", "#text": "Redesign the RAM devices to reduce inter capacitive coupling making the Rowhammer exploit impossible."}], "Body_Text": ["Preventing the loop required to defeat the Rowhammer exploit is not always possible:", "While the redesign may be possible for new devices, a redesign is not possible in existing devices. There is also the possibility that reducing capacitance with a relayout would impact the density of the device resulting in a less capable, more costly device."]}, {"Intro_Text": "Suppose a hardware design implements a set of software-accessible registers for scaling clock frequency and voltage but does not control access to these registers. Attackers may cause register and memory changes and race conditions by changing the clock or voltage of the device under their control."}, {"Intro_Text": "Consider the following SoC\n\t      design. Security-critical settings for scaling clock\n\t      frequency and voltage are available in a range of\n\t      registers bounded by [PRIV_END_ADDR : PRIV_START_ADDR]\n\t      in the tmcu.csr module in the HW Root of Trust. These\n\t      values are writable based on the lock_bit register in\n\t      the same module. The lock_bit is only writable by\n\t      privileged software running on the tmcu.", "Body_Text": {"xhtml:img": {"@src": "/data/images/HRoT-CWE.png", "@alt": "Hardware Root of Trust"}, "xhtml:p": "We assume that untrusted software running on any of the\n\t      Core{0-N} processors has access to the input and output\n\t      ports of the hrot_iface. If untrusted software can clear\n\t      the lock_bit or write the clock frequency and voltage\n\t      registers due to inadequate protection, a fault\n\t      injection attack could be performed."}}]}, "Observed_Examples": {"Observed_Example": [{"Reference": "CVE-2019-11157", "Description": "Plundervolt: Improper conditions check in voltage settings for some Intel(R) Processors may allow a privileged user to potentially enable escalation of privilege and/or information disclosure via local access [REF-1081].", "Link": "https://www.cve.org/CVERecord?id=CVE-2019-11157"}, {"Reference": "CVE-2020-8694", "Description": "PLATYPUS Attack: Insufficient access control in the Linux kernel driver for some Intel processors allows information disclosure.", "Link": "https://www.cve.org/CVERecord?id=CVE-2020-8694"}, {"Reference": "CVE-2020-8695", "Description": "Observable discrepancy in the RAPL interface for some Intel processors allows information disclosure.", "Link": "https://www.cve.org/CVERecord?id=CVE-2020-8695"}, {"Reference": "CVE-2020-12912", "Description": "AMD extension to a Linux service does not require privileged access to the RAPL interface, allowing side-channel attacks.", "Link": "https://www.cve.org/CVERecord?id=CVE-2020-12912"}, {"Reference": "CVE-2015-0565", "Description": "NaCl in 2015 allowed the CLFLUSH instruction, making Rowhammer attacks possible.", "Link": "https://www.cve.org/CVERecord?id=CVE-2015-0565"}]}, "Functional_Areas": {"Functional_Area": ["Power", "Clock"]}, "Related_Attack_Patterns": {"Related_Attack_Pattern": [{"@CAPEC_ID": "624"}, {"@CAPEC_ID": "625"}]}, "References": {"Reference": [{"@External_Reference_ID": "REF-1081"}, {"@External_Reference_ID": "REF-1082"}, {"@External_Reference_ID": "REF-1083"}, {"@External_Reference_ID": "REF-1225"}, {"@External_Reference_ID": "REF-1217"}]}, "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": "Nicole Fern", "Submission_Organization": "Cycuity (originally submitted as Tortuga Logic)", "Submission_Date": "2020-05-08", "Submission_Version": "4.1", "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 Demonstrative_Examples, Description, Maintenance_Notes, Related_Attack_Patterns"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2021-03-15", "Modification_Version": "4.4", "Modification_ReleaseDate": "2021-03-15", "Modification_Comment": "updated Demonstrative_Examples, Functional_Areas, Maintenance_Notes"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2021-07-20", "Modification_Version": "4.5", "Modification_ReleaseDate": "2021-07-20", "Modification_Comment": "updated Demonstrative_Examples, Observed_Examples"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2021-10-28", "Modification_Version": "4.6", "Modification_ReleaseDate": "2021-10-28", "Modification_Comment": "updated Demonstrative_Examples, Description, Detection_Factors, Maintenance_Notes, Modes_of_Introduction, Name, Observed_Examples, References, Relationships, Weakness_Ordinalities"}, {"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 Applicable_Platforms"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2022-06-28", "Modification_Version": "4.8", "Modification_ReleaseDate": "2022-06-28", "Modification_Comment": "updated Applicable_Platforms"}, {"Modification_Name": "CWE Content Team", "Modification_Organization": "MITRE", "Modification_Date": "2023-01-31", "Modification_Version": "4.10", "Modification_ReleaseDate": "2023-01-31", "Modification_Comment": "updated Related_Attack_Patterns"}, {"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": "2025-04-03", "Modification_Version": "4.17", "Modification_ReleaseDate": "2025-04-03", "Modification_Comment": "updated Demonstrative_Examples"}, {"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"}], "Contribution": [{"@Type": "Content", "Contribution_Organization": "Cycuity (originally submitted as Tortuga Logic)", "Contribution_Date": "2021-07-16", "Contribution_Comment": "Provided Demonstrative Example for Hardware Root of Trust"}, {"@Type": "Content", "Contribution_Name": "Anders Nordstrom, Alric Althoff", "Contribution_Organization": "Cycuity (originally submitted as Tortuga Logic)", "Contribution_Date": "2021-10-11", "Contribution_Comment": "Provided detection method"}, {"@Type": "Content", "Contribution_Name": "Nicole Fern", "Contribution_Organization": "Riscure", "Contribution_Date": "2021-10-15", "Contribution_Comment": "updated description and extended description, detection method, and observed examples"}], "Previous_Entry_Name": {"@Date": "2021-10-28", "#text": "Hardware Features Enable Physical Attacks from Software"}}}