Détail du CWE-1429

The product has a hardware interface that silently discards operations in situations for which feedback would be security-relevant, such as the timely detection of failures or attacks.

While some systems intentionally withhold feedback as a security measure, this approach must be strictly controlled to ensure it does not obscure operational failures that require prompt detection and remediation. Without these essential confirmations, failures go undetected, increasing the risk of data loss, security vulnerabilities, and overall system instability. Even when withholding feedback is an intentional part of a security policy designed, for example, to prevent attackers from gleaning sensitive internal details, the absence of expected feedback becomes a critical weakness when it masks operational failures that require prompt detection and remediation.

For instance, certain encryption algorithms always return ciphertext regardless of errors to prevent attackers from gaining insight into internal state details. However, if such an algorithm fails to generate the expected ciphertext and provides no error feedback, the system cannot distinguish between a legitimate output and a malfunction. This can lead to undetected cryptographic failures, potentially compromising data security and system reliability. Without proper notification, a critical failure might remain hidden, undermining both the reliability and security of the process.

Therefore, this weakness captures issues across various hardware interfaces where operations are discarded without any feedback, error handling, or logging. Such omissions can lead to data loss, security vulnerabilities, and system instability, with potential impacts ranging from minor to catastrophic.

For some kinds of hardware products, some errors may be correctly identified and subsequently discarded, and the lack of feedback may have been an intentional design decision. However, this could result in a weakness if system operators or other authorized entities are not provided feedback about security-critical operations or failures that could prevent the operators from detecting and responding to an attack.

For example:

• In a System-on-Chip (SoC) platform, write operations to reserved memory addresses might be correctly identified as invalid and subsequently discarded. However, if no feedback is provided to system operators, they may misinterpret the device's state, failing to recognize conditions that could lead to broader failures or security vulnerabilities. For example, if an attacker attempts unauthorized writes to protected regions, the system may silently discard these writes without alerting security mechanisms. This lack of feedback could obscure intrusion attempts or misconfigurations, increasing the risk of unnoticed system compromise
• Microcontroller Interrupt Systems: When interrupts are silently ignored due to priority conflicts or internal errors without notifying higher-level control, it becomes challenging to diagnose system failures or detect potential security breaches in a timely manner.
• Network Interface Controllers: Dropping packets - perhaps due to buffer overflows - without any error feedback can not only cause data loss but may also contribute to exploitable timing discrepancies that reveal sensitive internal processing details.

Modes d'introduction

Architecture and Design :

This weakness can be introduced during the architecture and design phase when the system does not incorporate proper mechanisms for error reporting or feedback for discarded operations, such as when handling reserved addresses or unexecuted instructions.

Implementation :

It can also arise during implementation if developers fail to include appropriate feedback or logging for critical operations. This leads to silent failures in certain scenarios like interrupt handling or network buffer overflows.

Requirements :

A further layer of complexity emerges when considering specifications. The weakness may stem either from ambiguous product design specifications that fail to delineate when feedback should occur or from implementations that do not adhere to existing requirements. In either case, the result is the same: feedback that is critical for detecting operational failures or security breaches is missing.

Plateformes applicables

Langue

Name: C (Undetermined)
Name: C++ (Undetermined)
Name: Verilog (Undetermined)
Class: Hardware Description Language (Undetermined)
Class: Not Language-Specific (Undetermined)

Architectures

Name: ARM (Undetermined)
Name: x86 (Undetermined)
Class: Embedded (Undetermined)

Technologies

Name: Security Hardware (Undetermined)
Name: Processor Hardware (Undetermined)
Name: Microcontroller Hardware (Undetermined)
Class: System on Chip (Undetermined)

Conséquences courantes

Exemples observés

Mesures d’atténuation potentielles

Phases : Architecture and Design

Incorporate logging and feedback mechanisms during the design phase to ensure proper handling of discarded operations.

Phases : Implementation

Developers should ensure that every critical operation includes proper logging or error feedback mechanisms.

Méthodes de détection

Automated Static Analysis - Source Code

Scans code for missing error handling or feedback mechanisms.

Efficacité : High

Manual Static Analysis - Source Code

Experts manually inspect the code for unhandled operations.

Efficacité : Moderate

Notes de cartographie des vulnérabilités

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.
Commentaire : 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.

Références

REF-1468

OpenTitan issue: [rv_core_ibex] Bus errors on integrity check failure
GregAC.
https://github.com/lowRISC/opentitan/issues/11336

Soumission