CWE-1256: Improper Restriction of Software Interfaces to Hardware Features

Description:
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.

Extended Description:
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 

Affected languages: Not Language-Specific
Affected technologies: Not Technology-Specific, Memory Hardware, Power Management Hardware, Clock/Counter Hardware
Parent weaknesses: CWE-285

Consequences:
  - Integrity: Modify Memory

Detection methods:
  - 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 effecti

Mitigations:
  - [Architecture and Design] Ensure proper access control mechanisms protect software-controllable features altering physical operating conditions such as clock frequency and voltage.

Demonstrative examples:
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.
Preventing the loop required to defeat the Rowhammer exploit is not always possible:
Continuously writing the same value to the same address causes the value of an adjacent location to change value.
Redesign the RAM devices to reduce inter capacitive coupling making the Rowhammer exploit impossible.

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.

Real-world examples:
  - 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 loca
  - CVE-2020-8694: PLATYPUS Attack: Insufficient access control in the Linux kernel driver for some Intel processors allows information disclosure.
  - CVE-2020-8695: Observable discrepancy in the RAPL interface for some Intel processors allows information disclosure.
  - CVE-2020-12912: AMD extension to a Linux service does not require privileged access to the RAPL interface, allowing side-channel attacks.
  - CVE-2015-0565: NaCl in 2015 allowed the CLFLUSH instruction, making Rowhammer attacks possible.