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.


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.

Demonstrations

The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.

Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.

Example One

The register interface provides software access to hardware functionality. This functionality is an attack surface. This attack surface may be used to run untrusted code on the system through the register interface. As an example, cryptographic accelerators require a mechanism for software to select modes of operation and to provide plaintext or ciphertext data to be encrypted or decrypted as well as other functions. This functionality is commonly provided through registers.

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.

Example Two

The example code is taken from the Control/Status Register (CSR) module inside the processor core of the HACK@DAC'19 buggy CVA6 SoC [REF-1340]. In RISC-V ISA [REF-1341], the CSR file contains different sets of registers with different privilege levels, e.g., user mode (U), supervisor mode (S), hypervisor mode (H), machine mode (M), and debug mode (D), with different read-write policies, read-only (RO) and read-write (RW). For example, machine mode, which is the highest privilege mode in a RISC-V system, registers should not be accessible in user, supervisor, or hypervisor modes.

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
end

The vulnerable example code allows the machine exception program counter (MEPC) register to be accessed from a user mode program by excluding the MEPC from the access control check. MEPC as per the RISC-V specification can be only written or read by machine mode code. Thus, the attacker in the user mode can run code in machine mode privilege (privilege escalation).

To mitigate the issue, fix the privilege check so that it throws an Illegal Instruction Exception for user mode accesses to the MEPC register. [REF-1345]

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)) 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
end

See Also

Comprehensive Categorization: Access Control

Weaknesses in this category are related to access control.

Privilege Separation and Access Control Issues

Weaknesses in this category are related to features and mechanisms providing hardware-based isolation and access control (e.g., identity, policy, locking control) of s...

Comprehensive CWE Dictionary

This view (slice) covers all the elements in CWE.

Weaknesses Introduced During Implementation

This view (slice) lists weaknesses that can be introduced during implementation.

Weaknesses Introduced During Design

This view (slice) lists weaknesses that can be introduced during design.


Common Weakness Enumeration content on this website is copyright of The MITRE Corporation unless otherwise specified. Use of the Common Weakness Enumeration and the associated references on this website are subject to the Terms of Use as specified by The MITRE Corporation.