logo

Expected Behavior Violation

Draft Base
Structure: Simple
Description

This weakness occurs when a software component, such as a function, API, or feature, fails to act as documented or intended. The system's actual behavior deviates from its promised specification, leading to unpredictable results.

Extended Description

At its core, this violation is a trust issue between the developer and the component's interface. When you call a function or use an API, you rely on its documented contract—what inputs it accepts, what processing it performs, and what outputs or side effects it guarantees. If the component silently breaks this contract, your application logic can fail, security assumptions can be invalidated, and the entire system's stability is compromised. This often stems from ambiguous documentation, implementation bugs, or unintended side effects that the spec didn't account for. For developers, mitigating this requires a proactive approach. First, treat specifications as critical requirements, not suggestions. Implement rigorous input validation and error handling even for 'trusted' components. Second, employ defensive programming practices: write comprehensive unit and integration tests that verify both the happy path and edge cases against the documented behavior. Fuzz testing can be particularly effective in uncovering unexpected behaviors. Finally, when designing your own APIs, ensure your specifications are precise, complete, and tested, as unclear docs are a primary cause of downstream violations.
Common Consequences 1
Scope: Other

Impact: Quality DegradationVaries by Context
Demonstrative Examples 1
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.

Code Example:

Bad
Verilog

module csr_regfile #(...)(...); ... // --------------------------- // CSR Write and update logic // --------------------------- ...

verilog

mie_d = (mie_q & ~mideleg_q) | (csr_wdata & mideleg_q) | utval_q;** end ... endcase end endmodule

The 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].

Code Example:

Good
Verilog

module csr_regfile #(...)(...); ... // --------------------------- // CSR Write and update logic // --------------------------- ...

verilog

mie_d = (mie_q & ~mideleg_q) | (csr_wdata & mideleg_q);** end ... endcase end endmodule
Observed Examples 3
CVE-2003-0187Program 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-3265Buffer overflow in product stems the use of a third party library function that is expected to have internal protection against overflows, but doesn't.
References 3
The RISC-V Instruction Set Manual Volume II: Privileged Architecture page 28
2021
https://riscv.org/wp-content/uploads/2017/05/riscv-privileged-v1.10.pdf(2024-01-16)
ID: REF-1384
csr_regfile.sv
2021
https://github.com/HACK-EVENT/hackatdac21/blob/b9ecdf6068445d76d6bee692d163fededf7a9d9b/piton/design/chip/tile/ariane/src/csr_regfile.sv(2024-01-16)
ID: REF-1385
Fix for csr_regfile.sv
2021
https://github.com/HACK-EVENT/hackatdac21/blob/2341c625a28d2fb87d370e32c45b68bd711cc43b/piton/design/chip/tile/ariane/src/csr_regfile.sv#L519C4-L522C20(2024-01-16)
ID: REF-1386
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Technologies:
ICS/OT : Undetermined
Modes of Introduction
Architecture and Design
Implementation
Operation
Related Weaknesses
ChildOf: Incorrect Provision of Specified Functionality (CWE-684)
Taxonomy Mapping
  • PLOVER
Notes
TheoreticalThe behavior of an application that is not consistent with the expectations of the developer may lead to incorrect use of the software.