Description
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.
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.
Potential Impact
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
Demonstrative Examples
Cryptographic key material stored in registers inside the cryptographic accelerator can be accessed by software.Key material stored in registers should never be accessible to software. Even if software can provide a key, all read-back paths to software should be disabled.if (csr_we || csr_read) begin
if ((riscv::priv_lvl_t'(priv_lvl_o & csr_addr.csr_decode.priv_lvl) != csr_addr.csr_decode.priv_lvl) && !(csr_addr.address==riscv::CSR_MEPC)) begin
csr_exception_o.cause = riscv::ILLEGAL_INSTR;
csr_exception_o.valid = 1'b1;
end
// check access to debug mode only CSRs
if (csr_addr_i[11:4] == 8'h7b && !debug_mode_q) begin
csr_exception_o.cause = riscv::ILLEGAL_INSTR;
csr_exception_o.valid = 1'b1;
end
endif (csr_we || csr_read) begin
if ((riscv::priv_lvl_t'(priv_lvl_o & csr_addr.csr_decode.priv_lvl) != csr_addr.csr_decode.priv_lvl)) begin
csr_exception_o.cause = riscv::ILLEGAL_INSTR;
csr_exception_o.valid = 1'b1;
end
// check access to debug mode only CSRs
if (csr_addr_i[11:4] == 8'h7b && !debug_mode_q) begin
csr_exception_o.cause = riscv::ILLEGAL_INSTR;
csr_exception_o.valid = 1'b1;
end
endMitigations & Prevention
Design proper policies for hardware register access from software.
Ensure that access control policies for register access are implemented in accordance with the specified design.
Detection Methods
- Manual Analysis Moderate — 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.
- Manual Analysis Moderate — 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 w
- Simulation / Emulation Moderate — 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
- Formal Verification High — 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 an
- Automated Analysis High — 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 m
- Architecture or Design Review Moderate — Manual documentation review of the system memory map, register specification, and permissions associated with accessing security-relevant functionality exposed via memory-mapped registers.
Real-World CVE Examples
| CVE ID | 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. |
Related Weaknesses
Frequently Asked Questions
What is CWE-1262?
CWE-1262 (Improper Access Control for Register Interface) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Base-level weakness. 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.
How can CWE-1262 be exploited?
Attackers can exploit CWE-1262 (Improper Access Control for Register Interface) to read memory, read application data, modify memory, modify application data, gain privileges or assume identity, bypass protection mechanism, unexpected state, alter execution logic. This weakness is typically introduced during the Architecture and Design, Implementation phase of software development.
How do I prevent CWE-1262?
Key mitigations include: Design proper policies for hardware register access from software.
What is the severity of CWE-1262?
CWE-1262 is classified as a Base-level weakness (Medium abstraction). It has been observed in 4 real-world CVEs.