A secure system is invariably subject to stresses, such as those caused by attack, erroneous or malicious inputs, hardware or software faults, unanticipated user behavior, and unexpected environmental changes that are outside the bounds of "normal operation." Yet the system must continue to deliver essential services in a timely manner, safely and securely. To accomplish this, the system must exhibit qualities such as robustness, reliability, error tolerance, fault tolerance, performance, and security. All of these system-quality attributes depend on consistent and comprehensive error handling that supports the goals of the overall system.
ISO/IEC TR 24772, Section section 6.39.1 [ISO/IEC TR 24772], says:
...
An error-handling policy must specify a comprehensive approach to error reporting and response. Components and routines should always generate status indicators, and all called routines should have their error returns checked. All input should be checked for compliance with the formal requirements for such input rather than be blindly trusted. Moreover, never assume, on the basis of specific knowledge about the system or its domain, that the success of a called routine is guaranteed. The failure to report or properly respond to errors or other anomalies from a system perspective can threaten the survivability of the system as a whole.
ISO/IEC TR 24772:2013, Section section 6.39.5 [ISO/IEC TR 24772:2013], describes the following mitigation strategies:
Software developers can avoid the vulnerability or mitigate its ill effects in the following ways:
- A strategy for fault handling should be decided. Consistency in fault handling should be the same with respect to critically similar parts.
- A multi-tiered approach of fault prevention, fault detection, and fault reaction should be used.
- System-defined components that assist in uniformity of fault handling should be used when available. For one example, designing a "runtime constraint handler" (as described in Annex K of [the C Standard]) permits the application to intercept various erroneous situations and perform one consistent response, such as flushing a previous transaction and restarting at the next one.
- When there are multiple tasks, a fault-handling policy should be specified whereby a task may
- halt, and keep its resources available for other tasks (perhaps permitting restarting of the faulting task)
- halt, and remove its resources (perhaps to allow other tasks to use the resources so freed, or to allow a recreation of the task)
- halt, and signal the rest of the program to likewise halt
...
Failure to adopt and implement a consistent and comprehensive error-handling policy is detrimental to system survivability and can result in a broad range of vulnerabilities depending on the operational characteristics of the system.
Recommendation | Severity | Likelihood | Detectable |
|---|
Repairable | Priority | Level |
|---|---|---|
ERR00-C |
Medium | Probable |
No |
No | P4 | L3 |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Related Guidelines
...
Automated Detection
Tool | Version | Checker | Description | ||||||
|---|---|---|---|---|---|---|---|---|---|
| Checks for situations where error information is not checked (rec. partially covered) |
Related Guidelines
...
| ISO/IEC TR 24772:2013 | Termination Strategy [REU] |
| MISRA |
| C:2012 | Rule |
| 17.1 (required) | |
| MITRE CWE | CWE-391, Unchecked error condition CWE-544, Missing standardized error handling mechanism |
Bibliography
| [Fisher 1999] |
| [Horton 1990] | Section 11, p. 168 |
Section 14, p. 254 | |
| [Koenig 1989] | Section 5.4, p. 73 |
| [Lipson 2000] |
| [Lipson 2006] |
| [Summit 2005] | C-FAQ Question 20.4 |
...