Difference between revisions of "Uncaught exception"

From OWASP
Jump to: navigation, search
Line 89: Line 89:
 
Not available.
 
Not available.
  
==Categories ==
 
  
 
[[Category:Vulnerability]]
 
[[Category:Vulnerability]]

Revision as of 23:06, 27 May 2006


Overview

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.

Consequences

Undefined.

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.

Platform

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

Required resources

Any

Severity

Medium

Likelihood of exploit

Medium

Avoidance and mitigation

  • 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.

Examples

In C++:

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

int
main(){
        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)
                exit(1);
        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.

Related problems

Not available.