Difference between revisions of "Uncaught exception"

Jump to: navigation, search
(5 intermediate revisions by the same user not shown)
Line 2: Line 2:
[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
[[ASDR Table of Contents]]
Ignoring an exception can cause the program to overlook unexpected states and conditions.
Ignoring an exception can cause the program to overlook unexpected states and conditions.
Line 141: Line 134:
[[Category:FIXME|add links
In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>
Availability Vulnerability
Authorization Vulnerability
Authentication Vulnerability
Concurrency Vulnerability
Configuration Vulnerability
Cryptographic Vulnerability
Encoding Vulnerability
Error Handling Vulnerability
Input Validation Vulnerability
Logging and Auditing Vulnerability
Session Management Vulnerability]]

Revision as of 15:13, 28 February 2009

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.

This article includes content generously donated to OWASP by Fortify.JPG.

Last revision (mm/dd/yy): 02/28/2009

Vulnerabilities Table of Contents


Ignoring an exception can cause the program to overlook unexpected states and conditions.

When an exception is thrown and not caught, the process has given up an opportunity to decide if a given failure or event is worth a change in execution.

Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this method call can never fail" and "it doesn't matter if this call fails". When a programmer ignores an exception, they implicitly state that they are operating under one of these assumptions.



Exposure period

  • Requirements specification: The choice could be made to use a language that is resistant to this issues.
  • Implementation: Many logic errors can lead to this condition. It can be exacerbated by lack, or misuse, of mitigating technologies. Generally this problem is either caused by using a foreign API or an API which the programmer is not familiar with.


  • Languages: Java, C++, C#, or any language which has exceptions.
  • Operating platforms: Any

Required resources




Likelihood of exploit


Risk Factors



In C++:

#include <iostream.h>
#include <new>
#include <stdlib.h>

        char            input[100];
        int             i, n;
        long           *l;

        Required resources        cout <<   many numbers do you want to type in? ";
        cin.getline(input, 100);
        i = atoi(input);
        //here we are purposly not checking to see if this call to 
        //new works
        //try {
                l = new long    [i];

        //catch (bad_alloc & ba) {
        //       cout << "Exception:" << endl;
        if (l == NULL)
        for (n = 0; n < i; n++) {
                cout << "Enter number: ";
                cin.getline(input, 100);
                l[n] = atol(input);
                cout << "You have entered: ";
        for (n = 0; n < i; n++)
                cout << l[n] << ", ";
        delete[] l;
        return 0;

In this example, since we do not check if new throws an exception, we can find strange failures if large values are entered.

In Java:

The following code excerpt ignores a rarely-thrown exception from doExchange().

	try {
	catch (RareException e) {
	  // this can never happen

If a RareException were to ever be thrown, the program would continue to execute as though nothing unusual had occurred. The program records no evidence indicating the special situation, potentially frustrating any later attempt to explain the program's behavior.

Related Attacks

Related Vulnerabilities

Related Controls

  • Control 1
  • Control 2
  • Requirements Specification: The choice between a language which has named or unnamed exceptions needs to be done. While unnamed exceptions exacerbate the chance of not properly dealing with an exception, named exceptions suffer from the up call version of the weak base class problem.
  • Requirements Specification: A language can be used which requires, at compile time, to catch all serious exceptions. However, one must make sure to use the most current version of the API as new exceptions could be added.
  • Implementation: Catch all relevant exceptions. This is the recommended solution. Ensure that all exceptions are handled in such a way that you can be sure of the state of your system at any given moment.

Related Technical Impacts