Handle All Errors Safely

Description

Error handling (or, more generally, "exception handling") is an essential aspect of reliability and security and is frequently a source of vulnerabilities. An ''error'' is an internal state not expected to occur during normal operation that, if not handled correctly, could lead to a failure to deliver the required service. Error handling consists of detecting such internal states and performing the required reaction to such events. The reaction might be some form of recovery such as a retry of a failed calculation.

In the case of errors that cannot be corrected, the Failing Securely principle councils one to take the most conservative reaction. The required reaction may consist of a "graceful" exit with appropriate notification of the failure to the calling procedure or program and to any components monitoring system health. Frequently the called function's return value is used to indicate an error, but a failure might also raise an exception, invoke a callback, or schedule a signal.

Successful error management also depends on the calling procedure recognizing and correctly reacting to an error generated on a call. However, the calling procedure itself might not have sufficient context to be able to handle the error in the way that is best for the system as a whole, especially in an object oriented systems. Therefore, the calling procedure may pass the exception up to its own calling procedure (perhaps with some additional context information) to improve the chances for successful recovery from an error. At the highest level, every error must be dealt with appropriately or extreme measure are required. The typical handler for unexpected top level exceptions is to terminate. But other reactions are possible, such as complete reinitialization of the system.

An ignored error or an improper reaction to an error will likely generate an inconsistent or unanticipated internal state in the calling program. "Unanticipated" implies that neither detection nor recovery is available for such errors and that a vulnerability, whose exploitation can lead to a system failure or an insecure state, may be possible [VU#795632¹].

The mechanisms used to report errors can also induce vulnerabilities. In languages that support exceptions, the evolution of a component may encourage the interception and silent suppression of new classes of exceptions within the component in order to preserve the component's original API, since raising or propagating new exceptions may require syntactical or semantic changes in calling code. The suppression of such exceptions can produce unexpected results, which can lead to vulnerabilities of this class. The prototypical case is the suppression of "checked" exceptions in Java.

Since error handling code typically deals with rare or infrequent events, it is not unusual for insufficient effort to be devoted to developing such code and for thorough testing of error handling code to be overlooked. This contributes to a lessening of reliability for the system as a whole and an increased probability that a vulnerability related to error handling exists.

References