Improper Restriction of Software Interfaces to Hardware Features

Stable Base
Structure: Simple
Description

This vulnerability occurs when a system's software interfaces to hardware features—like power, clock, or performance management—are not properly locked down. This allows attackers to misuse these interfaces from software to tamper with hardware memory or registers, or to gather sensitive data by observing physical side effects, without needing physical access to the device.

Extended Description

Many developers assume that attacks like fault injection or side-channel analysis require an attacker to physically touch the device. This assumption breaks down when software can directly control hardware features like voltage, clock speed, or power meters. Attackers can exploit these poorly restricted interfaces from a standard application to deliberately cause bit errors (faults) or to measure power consumption patterns, leading to privilege escalation, authentication bypass, or cryptographic key extraction. Common examples include abusing dynamic voltage and frequency scaling (DVFS) to induce faults, using hardware power meters (e.g., Intel RAPL) for side-channel analysis, or triggering Rowhammer-style bit flips via rapid memory accesses. Managing this at scale is difficult; an ASPM like Plexicus can help you track and remediate these hardware-interface flaws across your entire stack, correlating code patterns with potential runtime exploitation.

Common Consequences 1
Scope: Integrity

Impact: Modify MemoryModify Application DataBypass Protection Mechanism

Detection Methods 2
Manual Analysis
Perform a security evaluation of system-level architecture and design with software-aided physical attacks in scope.
Automated Dynamic AnalysisModerate
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.
Potential Mitigations 1
Phase: Architecture and DesignImplementation
Ensure proper access control mechanisms protect software-controllable features altering physical operating conditions such as clock frequency and voltage.
Demonstrative Examples 3
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.

Code Example:

Bad
Other

Continuously writing the same value to the same address causes the value of an adjacent location to change value.

Preventing the loop required to defeat the Rowhammer exploit is not always possible:

Code Example:

Good
Other

Redesign the RAM devices to reduce inter capacitive coupling making the Rowhammer exploit impossible.

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.
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.
Consider the following SoC design. Security-critical settings for scaling clock frequency and voltage are available in a range of registers bounded by [PRIV_END_ADDR : PRIV_START_ADDR] in the tmcu.csr module in the HW Root of Trust. These values are writable based on the lock_bit register in the same module. The lock_bit is only writable by privileged software running on the tmcu.
We assume that untrusted software running on any of the Core{0-N} processors has access to the input and output ports of the hrot_iface. If untrusted software can clear the lock_bit or write the clock frequency and voltage registers due to inadequate protection, a fault injection attack could be performed.
Observed Examples 5
CVE-2019-11157Plundervolt: 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].
CVE-2020-8694PLATYPUS Attack: Insufficient access control in the Linux kernel driver for some Intel processors allows information disclosure.
CVE-2020-8695Observable discrepancy in the RAPL interface for some Intel processors allows information disclosure.
CVE-2020-12912AMD extension to a Linux service does not require privileged access to the RAPL interface, allowing side-channel attacks.
CVE-2015-0565NaCl in 2015 allowed the CLFLUSH instruction, making Rowhammer attacks possible.
References 5
Plundervolt
Kit Murdock, David Oswald, Flavio D Garcia, Jo Van Bulck, Frank Piessens, and Daniel Gruss
ID: REF-1081
CLKSCREW: Exposing the Perils of Security-Oblivious Energy Management
Adrian Tang, Simha Sethumadhavan, and Salvatore Stolfo
ID: REF-1082
Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors
Yoongu Kim, Ross Daly, Jeremie Kim, Ji Hye Lee, Donghyuk Lee, Chris Wilkerson, Konrad Lai, and Onur Mutlu
ID: REF-1083
Exploiting the DRAM rowhammer bug to gain kernel privileges
Project Zero
09-03-2015
ID: REF-1225
Security Engineering
Ross Anderson
2001
ID: REF-1217
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Technologies:
Not Technology-Specific : UndeterminedMemory Hardware : UndeterminedPower Management Hardware : UndeterminedClock/Counter Hardware : Undetermined
Modes of Introduction
Architecture and Design
Implementation
Functional Areas
  1. Power
  2. Clock
Related Weaknesses