Error handling is critical to the success and security of your application. It is necessary to adopt and implement a consistent error handling policy that is consistent with the goals and requirements of your application domain.
ISO/IEC PDTR 24772 Section 6.47, "REU Termination strategy" says:
Expectations that a system will be dependable are based on the confidence that the system will operate as expected and not fail in normal use. The dependability of a system and its fault tolerance can be measured through the component part's reliability, availability, safety and security. Reliability is the ability of a system or component to perform its required functions under stated conditions for a specified period of time IEEE 1990 glossary. Availability is how timely and reliable the system is to its intended users. Both of these factors matter highly in systems used for safety and security. In spite of the best intentions, systems will encounter a failure, either from internally poorly written software or external forces such as power outages/variations, floods, or other natural disasters. The reaction to a fault can affect the performance of a system and in particular, the safety and security of the system and its users.
When a fault is detected, there are many ways in which a system can react. The quickest and most noticeable way is to fail hard, also known as fail fast or fail stop. The reaction to a detected fault is to immediately halt the system. Alternatively, the reaction to a detected fault could be to fail soft. The system would keep working with the faults present, but the performance of the system would be degraded. Systems used in a high availability environment such as telephone switching centers, e-commerce, etc. would likely use a fail soft approach. What is actually done in a fail soft approach can vary depending on whether the system is used for safety critical or security critical purposes. For fail safe systems, such as flight controllers, traffic signals, or medical monitoring systems, there would be no effort to meet normal operational requirements, but rather to limit the damage or danger caused by the fault. A system that fails securely, such as cryptologic systems, would maintain maximum security when a fault is detected, possibly through a denial of service.
ISO/IEC PDTR 24772 Section 6.47, "REU Termination strategy" also says:
The reaction to a fault in a system can depend on the criticality of the part in which the fault originates. When a program consists of several tasks, the tasks each may be critical, or not. If a task is critical, it may or may not be restartable by the rest of the program. Ideally, a task which detects a fault within itself should be able to halt leaving its resources available for use by the rest of the program, halt clearing away its resources, or halt the entire program. The latency of any such communication, and whether other tasks can ignore such a communication, should be clearly specified. Having inconsistent reactions to a fault, such as the fault reaction to a crypto fault, can potentially be a vulnerability.
ISO/IEC PDTR 24772 Section 6.47, "REU Termination strategy" 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 ISO/IEC TR 24731-1) permits the application to intercept various erroneous situations and perform one consistent response, such as flushing a previous transaction and re-starting 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.
Risk Analysis
Failing to detect error condition can result in unexpected program behavior, and possibly abnormal program termination resulting in a denial-of-service condition.
Recommendation |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
|---|---|---|---|---|---|
ERR00-A |
2 (medium) |
2 (probable) |
2 (medium) |
P8 |
L2 |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
[[Horton 90]] Section 11 p. 168, Section 14 p. 254
[[ISO/IEC 9899-1999]] Sections 7.1.4, 7.9.10.4, and 7.11.6.2
[[ISO/IEC PDTR 24772]] "NZN Returning error status"
[[Koenig 89]] Section 5.4 p. 73
[[MISRA 04]] Rule 16.1
[[Summit 05]] C-FAQ Question 20.4
13. Error Handling with errno (ERR) 13. Error Handling with errno (ERR) ERR01-A. Use ferror() rather than errno to check for any accumulated error