The product provides software-controllable
device functionality for capabilities such as power and
clock management, but it does not properly limit
functionality that can lead to modification of
hardware memory or register bits, or the ability to
observe physical side channels.

It is frequently assumed that physical attacks
such as fault injection and side-channel analysis
require an attacker to have physical access to the
target device. This assumption may be false if the
device has improperly secured power management features,
or similar features. For mobile devices, minimizing
power consumption is critical, but these devices run a
wide variety of applications with different performance
requirements. Software-controllable mechanisms to
dynamically scale device voltage and frequency and
monitor power consumption are common features in today's
chipsets, but they also enable attackers to mount fault
injection and side-channel attacks without having
physical access to the device.

Fault injection attacks involve strategic
manipulation of bits in a device to achieve a desired
effect such as skipping an authentication step,
elevating privileges, or altering the output of a
cryptographic operation. Manipulation of the device
clock and voltage supply is a well-known technique to
inject faults and is cheap to implement with physical
device access. Poorly protected power management
features allow these attacks to be performed from
software. Other features, such as the ability to write
repeatedly to DRAM at a rapid rate from unprivileged
software, can result in bit flips in other memory
locations (Rowhammer, [REF-1083]).

Side channel analysis requires gathering
measurement traces of physical quantities such as power
consumption. Modern processors often include power
metering capabilities in the hardware itself (e.g.,
Intel RAPL) which if not adequately protected enable
attackers to gather measurements necessary for
performing side-channel attacks from software.

Primary

Architecture and Design
An architect may initiate introduction of
this weakness via exacting requirements for
software accessible power/clock management
requirements

Implementation
An implementer may introduce this weakness
by assuming there are no consequences to unbounded
power and clock management for secure components
from untrusted ones.

Integrity
Modify Memory
Modify Application Data
Bypass Protection Mechanism

Manual Analysis
Perform a security evaluation of system-level
architecture and design with software-aided physical attacks
in scope.

Automated Dynamic Analysis

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.

Moderate

Architecture and Design
Implementation

Ensure proper access control mechanisms protect software-controllable features altering physical operating conditions such as clock frequency and voltage.

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.

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:

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.

CVE-2019-11157
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].
https://www.cve.org/CVERecord?id=CVE-2019-11157

CVE-2020-8694
PLATYPUS Attack: Insufficient access control in the Linux kernel driver for some Intel processors allows information disclosure.
https://www.cve.org/CVERecord?id=CVE-2020-8694

CVE-2020-8695
Observable discrepancy in the RAPL interface for some Intel processors allows information disclosure.
https://www.cve.org/CVERecord?id=CVE-2020-8695

CVE-2020-12912
AMD extension to a Linux service does not require privileged access to the RAPL interface, allowing side-channel attacks.
https://www.cve.org/CVERecord?id=CVE-2020-12912

CVE-2015-0565
NaCl in 2015 allowed the CLFLUSH instruction, making Rowhammer attacks possible.
https://www.cve.org/CVERecord?id=CVE-2015-0565

Power
Clock

Allowed
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.
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.

Nicole Fern
Cycuity (originally submitted as Tortuga Logic)
2020-05-08
4.1
2020-02-24

CWE Content Team
MITRE
2020-08-20
updated Demonstrative_Examples, Description, Maintenance_Notes, Related_Attack_Patterns

CWE Content Team
MITRE
2021-03-15
updated Demonstrative_Examples, Functional_Areas, Maintenance_Notes

CWE Content Team
MITRE
2021-07-20
updated Demonstrative_Examples, Observed_Examples

CWE Content Team
MITRE
2021-10-28
updated Demonstrative_Examples, Description, Detection_Factors, Maintenance_Notes, Modes_of_Introduction, Name, Observed_Examples, References, Relationships, Weakness_Ordinalities

CWE Content Team
MITRE
2022-04-28
updated Applicable_Platforms

CWE Content Team
MITRE
2022-06-28
updated Applicable_Platforms

CWE Content Team
MITRE
2023-01-31
updated Related_Attack_Patterns

CWE Content Team
MITRE
2023-04-27
updated Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2025-04-03
4.17
2025-04-03
updated Demonstrative_Examples

CWE Content Team
MITRE
2025-09-09
4.18
2025-09-09
updated Relationships

Cycuity (originally submitted as Tortuga Logic)
2021-07-16
Provided Demonstrative Example for Hardware Root of Trust

Anders Nordstrom, Alric Althoff
Cycuity (originally submitted as Tortuga Logic)
2021-10-11
Provided detection method

Nicole Fern
Riscure
2021-10-15
updated description and extended description, detection method, and observed examples

Hardware Features Enable Physical Attacks from Software