Page History

Programmers often suppress checked exceptions by catching exceptions with an empty or trivial catch block. Each catch block must ensure that the program continues only with valid invariants. Consequently, the catch block must either recover from the exceptional condition, re-throw rethrow the exception to allow the next nearest dynamically enclosing catch clause of a try statement to recover, or throw an exception that is appropriate to the context of the catch block.

Exceptions disrupt the expected control flow of the application. For example, no part of any expressions expression or statement that occurs in the try block after the point from which the exception is thrown may appear to have been is evaluated. Consequently, exceptions must be handled appropriately. There are few valid reasons for suppressing exceptions; the most common are cases where is when the client cannot be expected to recover from the underlying problem. In these cases, it is good practice to allow the exception to propagate outwards rather than to catch and suppress the exception.

Noncompliant Code Example

Printing This noncompliant code example simply prints the exception's stack trace can be useful for debugging purposes but results in program execution that is equivalent to suppressing the exception. Printing the stack trace can also result in unintentionally leaking information about the structure and state of the process to an attacker. (See ERR01-J. Do not allow exceptions to expose sensitive information for more information.).

try {
  //...
} catch (IOException ioe) {
  ioe.printStacktrace();
}

Printing the exception's stack trace can be useful for debugging purposes, but the resulting program execution is equivalent to suppressing the exception. Printing the stack trace can also leak information about the structure and state of the process to an attacker. (See rule ERR01-J. Do not allow exceptions to expose sensitive information for more information.) Note that even though the application this noncompliant code example reacts to the exception by printing out a stack trace, it then proceeds as though the exception were not thrown. That is, the behavior of the application is unaffected by the throwing of the exception being thrown, except that any expressions or statements that occur in the try block after the point from which the exception is thrown are not evaluated.

Compliant Solution (Interactive)

This compliant solution attempts to recover from handles a FileNotFoundException by requesting that the user specify another file name.

boolean volatile validFlag = false;
do {
  try {
    // If requested file does not exist, throws FileNotFoundException
    // If requested file exists, sets a Boolean flag validFlag to true
    validFlag = true;
  } catch (FileNotFoundException e) {
    // Ask the user for a different file name
  }
} while (validFlag != true);
// Use the file

To comply with rule ERR01-J. Do not allow exceptions to expose sensitive information, the user is should only be allowed to access files in a user-specific directory. This prevents any other IOException that escapes the loop from leaking sensitive file system information.

...

Proper reporting of exceptional conditions is context-dependent. For example, GUI applications should report the exception in a graphical manner, such as in an error dialog box. Most library classes should be able to objectively determine how an exception should be reported to preserve modularity; they cannot rely on System.err, on any particular logger, or on the availability of the windowing environment. As a result, library classes that wish to report exceptions should specify the API they use to report exceptions:report exceptions. This compliant solution specifies both an interface for reporting exceptions, which exports the report() method, and a default exception reporter class that the library can use. The exception reporter can be overridden by subclasses.

public interface Reporter {
  public void report(Throwable t);
}

public class ExceptionReporter {

  // Exception reporter that prints the exception 
  // to the console (used as default)
  private static final Reporter PrintException = new Reporter() {
    public void report(Throwable t) {
      System.err.println(t.toString());
    }
  };

  // Stores the default reporter.
  // The default reporter can be changed by the user.
  private static Reporter Default = PrintException;

  // Helps change the default reporter back to 
  // PrintException in the future
  public static Reporter getPrintException() {
    return PrintException;
  }

  public static Reporter getExceptionReporter() {
    return Default;
  }

  public static void setExceptionReporter(Reporter reporter) {
    try {
      // Custom permission
      ExceptionReporterPermission perm = new 
          ExceptionReporterPermission("exc.reporter"); // Custom permission
      SecurityManager sm = System.getSecurityManager();
        if (sm != null) {
          // Check whether the caller has appropriate permissions
          sm.checkPermission(perm);
        }

      Default = reporter; // Change the default exception reporter
      Default = reporter; 
    } catch (SecurityException se) {
      System.out.println("Not allowed"); // or log
    }
  }
}

...

  }
}

The setExceptionReporter() method prevents hostile code from maliciously installing a more verbose reporter that leaks sensitive information or that directs exception reports to an inappropriate location, such as the attacker's computer, by limiting attempts to change the exception reporter to callers that have the custom permission ExceptionReporterPermission with target exc.reporter.

...

Any client code that possesses the required permissions can override the ExceptionReporter with a handler that logs the error , or provides a dialog box, or both. For instance, a GUI client using Swing may require exceptions to be reported using a dialog box:

...

Sometimes exceptions must be hidden from the user for security reasons (see rule ERR01-J. Do not allow exceptions to expose sensitive information. In such cases, one acceptable approach is to subclass the ExceptionReporter class and add a filter() method in addition to overriding the default report() method.

class MyExceptionReporter extends ExceptionReporter {
  private static final Logger logger =
      Logger.getLogger("com.organization.Log");

  public static void report(Throwable t) {
    try {
      final Throwable filteredException =
          (t instanceof NonSensitiveException_1) ? t : filter(t);
    } finally {
      // Do any necessary user reporting
      // (show dialog box or send to console)
      if (filteredException instanceof NonSensitiveCommonException) {
        logger.log(Level.FINEST, "Loggable exception occurred", t);
      }
    }
  }

  public static Exception filter(Throwable t) {
    if (t instanceof SensitiveForLoggingException_1) { 
      // Do not log sensitive information (blacklist)
      return SensitiveCommonException();
    }
    // ...
    return new NonSensitiveCommonException(); // Return for reporting to the user
    return new NonSensitiveCommonException(); 
  }
}

The {{report()}} method accepts a {{Throwable}} instance and consequently handles all errors, checked exceptions, and unchecked exceptions. The filtering mechanism is based on a _whitelisting_ approach wherein only non-sensitive exceptions are propagated to the user. Exceptions that are forbidden to appear in a log file can be filtered in the same fashion (see rule [FIO13-J. Do not log sensitive information outside a trust boundary]. This approach provides the benefits of exception chaining by reporting exceptions tailored to the abstraction while also logging the low -level cause for later failure analysis \[[Bloch 2008|AA. Bibliography#Bloch 08]\].

...

This code prevents calling methodscallers of the {{run()}} method from determining that an interrupted exception occurred. Consequently, thesethe caller methods are unable tosuch as {{Thread.start()}} cannot act on the exception \[[Goetz 2006|AA. Bibliography#Goetz 06]\].  Likewise, if this code waswere called in its own thread, it would prevent the calling thread from knowing that the thread was interrupted.

...

ERR00-EX0: Exceptions that occur during the freeing of a resource may be suppressed in those cases where failure to free the resource cannot affect future program behavior. Examples of freeing resources include closing files, network sockets, shutting down threads, and so forth. Such resources are generally freed in catch or finally blocks , and are often never reused during subsequent execution. Consequently, the exception cannot influence future program behavior through any avenue other than resource exhaustion. When resource exhaustion is adequately handled, it is sufficient to sanitize and log the exception for future improvement; additional error handling is unnecessary in this case.

...

*ERR00-EX2:* An {{InterruptedException}} may be caught and suppressed when extending class {{Thread}}. \[[Goetz 2006|AA. Bibliography#Goetz 06]\].  AAn interruption request may also be suppressed by code that implements a thread's interruption policy \[[Goetz 2006|AA. Bibliography#Goetz 06], pgp. 143\].

Risk Assessment

Ignoring or suppressing exceptions violates the fail-safe criteria of an application.

...

Detection of suppressed exceptions is straightforward. Sound determination of which specific cases represent violations of this rule and which represent permitted exceptions to the rule is infeasible. Heuristic approaches may be effective.

Related Vulnerabilities

be effective.

Related Vulnerabilities

AMQ-1272 describes a vulnerability in the ActiveMQ service. When ActiveMQ receives an invalid username and password from a Stomp client, a security exception is generated but is subsequently ignored, leaving the client connected, and with full and unrestricted access to ActiveMQ.AMQ-1272

Related Guidelines

Bibliography

...