Description
A feature, API, or function does not perform according to its specification.
Potential Impact
Other
Quality Degradation, Varies by Context
Demonstrative Examples
The provided code is extracted from the Control and Status Register (CSR), csr_regfile, module within the Hack@DAC'21 OpenPiton System-on-Chip (SoC). This module is designed to implement CSR registers in accordance with the RISC-V specification. The mie (machine interrupt enable) register is a 64-bit register [REF-1384], where bits correspond to different interrupt sources. As the name suggests, mie is a machine-level register that determines which interrupts are enabled. Note that in the example below the mie_q and mie_d registers represent the conceptual mie reigster in the RISC-V specification. The mie_d register is the value to be stored in the mie register while the mie_q register holds the current value of the mie register [REF-1385].
The mideleg (machine interrupt delegation) register, also 64-bit wide, enables the delegation of specific interrupt sources from machine privilege mode to lower privilege levels. By setting specific bits in the mideleg register, the handling of certain interrupts can be delegated to lower privilege levels without engaging the machine-level privilege mode. For example, in supervisor mode, the mie register is limited to a specific register called the sie (supervisor interrupt enable) register. If delegated, an interrupt becomes visible in the sip (supervisor interrupt pending) register and can be enabled or blocked using the sie register. If no delegation occurs, the related bits in sip and sie are set to zero.
The sie register value is computed based on the current value of mie register, i.e., mie_q, and the mideleg register.
Bad
module csr_regfile #(...)(...);
...
// ---------------------------
// CSR Write and update logic
// ---------------------------
...
if (csr_we) begin
unique case (csr_addr.address)
...
riscv::CSR_SIE: begin
// the mideleg makes sure only delegate-able register
//(and therefore also only implemented registers) are written
mie_d = (mie_q & ~mideleg_q) | (csr_wdata & mideleg_q) | utval_q;
end
...
endcase
end
endmoduleThe above code snippet illustrates an instance of a vulnerable implementation of the sie register update logic, where users can tamper with the mie_d register value through the utval (user trap value) register. This behavior violates the RISC-V specification.
The code shows that the value of utval, among other signals, is used in updating the mie_d value within the sie update logic. While utval is a register accessible to users, it should not influence or compromise the integrity of sie. Through manipulation of the utval register, it becomes feasible to manipulate the sie register's value. This opens the door for potential attacks, as an adversary can gain control over or corrupt the sie value. Consequently, such manipulation empowers an attacker to enable or disable critical supervisor-level interrupts, resulting in various security risks such as privilege escalation or denial-of-service attacks.
A fix to this issue is to remove the utval from the right-hand side of the assignment. That is the value of the mie_d should be updated as shown in the good code example [REF-1386].
Good
module csr_regfile #(...)(...);
...
// ---------------------------
// CSR Write and update logic
// ---------------------------
...
if (csr_we) begin
unique case (csr_addr.address)
...
riscv::CSR_SIE: begin
// the mideleg makes sure only delegate-able register
//(and therefore also only implemented registers) are written
mie_d = (mie_q & ~mideleg_q) | (csr_wdata & mideleg_q);
end
...
endcase
end
endmoduleReal-World CVE Examples
| CVE ID | Description |
|---|---|
| CVE-2003-0187 | Program uses large timeouts on unconfirmed connections resulting from inconsistency in linked lists implementations. |
| CVE-2003-0465 | "strncpy" in Linux kernel acts different than libc on x86, leading to expected behavior difference - sort of a multiple interpretation error? |
| CVE-2005-3265 | Buffer overflow in product stems the use of a third party library function that is expected to have internal protection against overflows, but doesn't. |
Related Weaknesses
Taxonomy Mappings
- PLOVER: — Expected behavior violation
Frequently Asked Questions
What is CWE-440?
CWE-440 (Expected Behavior Violation) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Base-level weakness. A feature, API, or function does not perform according to its specification.
How can CWE-440 be exploited?
Attackers can exploit CWE-440 (Expected Behavior Violation) to quality degradation, varies by context. This weakness is typically introduced during the Architecture and Design, Implementation, Operation phase of software development.
How do I prevent CWE-440?
Follow secure coding practices, conduct code reviews, and use automated security testing tools (SAST/DAST) to detect this weakness early in the development lifecycle.
What is the severity of CWE-440?
CWE-440 is classified as a Base-level weakness (Medium abstraction). It has been observed in 3 real-world CVEs.