CWE-1262 Detail

CWE-1262

Improper Access Control for Register Interface
Stable
2020-02-24
00h00 +00:00
2023-10-26
00h00 +00:00
Notifications for a CWE
Stay informed of any changes for a specific CWE.
Notifications manage

Name: Improper Access Control for Register Interface

The product uses memory-mapped I/O registers that act as an interface to hardware functionality from software, but there is improper access control to those registers.

CWE Description

Software commonly accesses peripherals in a System-on-Chip (SoC) or other device through a memory-mapped register interface. Malicious software could tamper with any security-critical hardware data that is accessible directly or indirectly through the register interface, which could lead to a loss of confidentiality and integrity.

General Informations

Modes Of Introduction

Architecture and Design : This weakness may be exploited if the register interface design does not adequately protect hardware assets from software.
Implementation : Mis-implementation of access control policies may inadvertently allow access to hardware assets through the register interface.

Applicable Platforms

Language

Class: Not Language-Specific (Undetermined)

Operating Systems

Class: Not OS-Specific (Undetermined)

Architectures

Class: Not Architecture-Specific (Undetermined)

Technologies

Class: Not Technology-Specific (Undetermined)

Common Consequences

Scope Impact Likelihood
Confidentiality
Integrity
Read Memory, Read Application Data, Modify Memory, Modify Application Data, Gain Privileges or Assume Identity, Bypass Protection Mechanism, Unexpected State, Alter Execution Logic

Note: Confidentiality of hardware assets may be violated if the protected information can be read out by software through the register interface. Registers storing security state, settings, other security-critical data may be corruptible by software without correctly implemented protections.

Observed Examples

References Description

CVE-2014-2915

virtualization product does not restrict access to debug and other processor registers in the hardware, allowing a crash of the host or guest OS

CVE-2021-3011

virtual interrupt controller in a virtualization product allows crash of host by writing a certain invalid value to a register, which triggers a fatal error instead of returning an error code

CVE-2020-12446

Driver exposes access to Model Specific Register (MSR) registers, allowing admin privileges.

CVE-2015-2150

Virtualization product does not restrict access to PCI command registers, allowing host crash from the guest.

Potential Mitigations

Phases : Architecture and Design
Design proper policies for hardware register access from software.
Phases : Implementation
Ensure that access control policies for register access are implemented in accordance with the specified design.

Detection Methods

Manual Analysis

This is applicable in the Architecture phase before implementation started. Make sure access policy is specified for the entire memory map. Manual analysis may not ensure the implementation is correct.
Effectiveness : Moderate

Manual Analysis

Registers controlling hardware should have access control implemented. This access control may be checked manually for correct implementation. Items to check consist of how are trusted parties set, how are trusted parties verified, how are accesses verified, etc. Effectiveness of a manual analysis will vary depending upon how complicated the interface is constructed.
Effectiveness : Moderate

Simulation / Emulation

Functional simulation is applicable during the Implementation Phase. Testcases must be created and executed for memory mapped registers to verify adherence to the access control policy. This method can be effective, since functional verification needs to be performed on the design, and verification for this weakness will be included. There can be difficulty covering the entire memory space during the test.
Effectiveness : Moderate

Formal Verification

Formal verification is applicable during the Implementation phase. Assertions need to be created in order to capture illegal register access scenarios and prove that they cannot occur. Formal methods are exhaustive and can be very effective, but creating the cases for large designs may be complex and difficult.
Effectiveness : High

Automated Analysis

Information flow tracking can be applicable during the Implementation phase. Security sensitive data (assets) - for example, as stored in registers - is automatically tracked over time through the design to verify the data doesn't reach illegal destinations that violate the access policies for the memory map. This method can be very effective when used together with simulation and emulation, since detecting violations doesn't rely on specific scenarios or data values. This method does rely on simulation and emulation, so testcases must exist in order to use this method.
Effectiveness : High

Architecture or Design Review

Manual documentation review of the system memory map, register specification, and permissions associated with accessing security-relevant functionality exposed via memory-mapped registers.
Effectiveness : Moderate

Fuzzing

Perform penetration testing (either manual or semi-automated with fuzzing) to verify that access control mechanisms such as the memory protection units or on-chip bus firewall settings adequately protect critical hardware registers from software access.
Effectiveness : Moderate

Vulnerability Mapping Notes

Justification : 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.
Comment : 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.

Related Attack Patterns

CAPEC-ID Attack Pattern Name
CAPEC-680 Exploitation of Improperly Controlled Registers

An adversary exploits missing or incorrectly configured access control within registers to read/write data that is not meant to be obtained or modified by a user.

References

REF-1340

Hackatdac19 csr_regfile.sv
https://github.com/HACK-EVENT/hackatdac19/blob/619e9fb0ef32ee1e01ad76b8732a156572c65700/src/csr_regfile.sv#L854:L857

REF-1341

The RISC-V Instruction Set Manual
Andrew Waterman, Yunsup Lee, Rimas Avižienis, David Patterson, Krste Asanović.
https://people.eecs.berkeley.edu/~krste/papers/riscv-privileged-v1.9.1.pdf

REF-1345

csr_regfile.sv
Florian Zaruba, Michael Schaffner, Andreas Traber.
https://github.com/openhwgroup/cva6/blob/7951802a0147aedb21e8f2f6dc1e1e9c4ee857a2/src/csr_regfile.sv#L868:L871

Submission

Name Organization Date Date release Version
Nicole Fern Cycuity (originally submitted as Tortuga Logic) 2020-05-08 +00:00 2020-02-24 +00:00 4.1

Modifications

Name Organization Date Comment
CWE Content Team MITRE 2020-08-20 +00:00 updated Common_Consequences, Demonstrative_Examples, Description, Maintenance_Notes, Modes_of_Introduction, Potential_Mitigations, Related_Attack_Patterns
CWE Content Team MITRE 2021-10-28 +00:00 updated Description, Detection_Factors, Name, Observed_Examples, Potential_Mitigations, Weakness_Ordinalities
CWE Content Team MITRE 2022-04-28 +00:00 updated Related_Attack_Patterns
CWE Content Team MITRE 2023-04-27 +00:00 updated Relationships
CWE Content Team MITRE 2023-06-29 +00:00 updated Demonstrative_Examples, Mapping_Notes, References
CWE Content Team MITRE 2023-10-26 +00:00 updated Demonstrative_Examples