Page History

Exceptions that are thrown while logging is in progress can prevent successful logging unless special care is taken. Failure to account for exceptions during the logging process causes can cause security vulnerabilities, including denial of service or vulnerabilities that allow an attacker to conceal critical security exceptions by preventing them from being logged. Consequently, programs must ensure that data logging continues to operate correctly even when exceptions are thrown during the logging process.

...

This noncompliant code example uses statements that can throw exceptions while logging is underway. It attempts to log a SecurityException generated within the run() method. However, in the event of an exception thrown while logging is underway, the original log message is lostwrites a critical security exception to the standard error stream.

public class ExceptionLog implements Runnable {
  public void logMessage(String message) {
    FileOutputStream fo = null;
    FileLock lock = null;

    try {
      // This can throw an exception and prevent logging.
      fo = new FileOutputStream("log_file.txt", true); 

      // Lock the file so only one thread can write a log message at a time.
      lock = fo.getChannel().lock();

      // Output the log message.
      System.err.println(message);
      fo.write((message + Runtime.getProperty("line.separator").getBytes());
    } 

    // If an exception is caught, the original log message is lost
    catch (FileNotFoundException e){
      logMessage("File Not Found Exception."); 
    }
    catch (IOExceptionSecurityException ese) {
      logMessage("IO Exception."); 
    }
    catch (OverlappingFileLockException e) {
      logMessage("Cannot access file.");
    }
    finally {
      // Clean up by releasing the file lock and closing the file.
      try {
        if (lock != null) {
          lock.release();
        }
        
        if (fo != null) {
          fo.close();
        }
      } catch (IOException e) {
        // This is unexpected.
        throw new RuntimeExceptionSystem.err.println(e);
      }
    }
  }

  public void run() {
    try {
      // SomeRecover security exception occurs here.
    } catch (SecurityException se) {
        logMessage("Security Exception has occurred!");
    }
  }

  public static void main(String[] args) {
    // Start multiple threads logging messages.
    for (int x = 1; x <= 20; x++) {
      (new Thread(new ExceptionLog())).start();
    }
  }    
}

This noncompliant code example throws an exception when there is a problem with the application's file system or when a thread attempts to write to the log file while it is locked by another thread. An attacker can exploit this code by:

...

from exception
}

Writing such exceptions to the standard error stream is insufficient. First, the standard error stream may be exhausted, preventing recording of subsequent exceptions. Second, the trust level of the standard error stream may be insufficient for recording certain security critical exceptions or errors without leaking sensitive information. If an I/O error occurs while writing the security exception, the catch clause will throw an IOException, and the critical security exception will be forgotten. Finally, an attacker may attempt to disguise the exception so that it occurs with several other innocuous exceptions.

Similarly, using Console.printf(), System.out.print*() or e.printStackTrace() to output a security exception also constitutes a violation of this guideline.

Compliant Solution

This compliant solution uses the thread and exception safe java.util.logging.Logger class to implement logging. Although there are several statements that can throw exceptions, all of them execute before any security critical operations; consequently any exceptions thrown from these statements cannot interfere with logging during the security critical operations. See guideline ERR03-J. Use a logging API to log critical security exceptions for more information on the use of logging libraries, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permitted.

public class ExceptionLog implements Runnable {
  Logger logger;
  Integer id;

  public ExceptionLog(Integer i, Logger log) {
    logger = log;
    id = i;
  }

  public void logMessage(String message) {
    // Note that the Java Logger class does not throw exceptions
  try {
  // while logging a message.
    logger.log(Level.WARNING, "From " + id + ": " + message);
  }

  public void run() {
    try {
      // Some security exception occurs here.
    } catch (SecurityException se) {
        logMessage("Security Exception has occurred!");
    }
  }

  public static void main(String[] args) {
    try {
      // Set up the shared logger for use by the multiple threads
      Logger logger = Logger.getLogger("MyLog");
      FileHandler fh = new FileHandler("log_file.txt", true);
      logger.addHandler(fh);
      logger.setLevel(Level.ALL);
      SimpleFormatter formatter = new SimpleFormatter();
      fh.setFormatter(formatter);

      // Start multiple threads for logging messages
      for (int x = 1; x <= 20; x++) {
        (new Thread(new ExceptionLog(x, logger))).start();
      }
    } catch (SecurityException e) {
        // This is unexpected.
        throw new RuntimeException(e);
    } catch (IOException e) {
        // This is unexpected.
        throw new RuntimeException(e);
    }
  }    
}

In this compliant solution, exceptions cannot cause either failure to log a message or logging a different message than was intended. Although this is a stringent requirement, it is necessary in cases where an an attacker can attempt to conceal his tracks by inducing throwing of an exception. The logging mechanism must be robust and should be able to detect and handle all such cases. Support for recursive logging is also an acceptable solution, but is slightly more expensive to implement.

(Level.SEVERE, se);
  // Recover from exception
}

Typically, only one logger is required for the whole program.

Exceptions

EXC07-EX0: Some application servers such as IBM's WebSphere automatically log critical security exceptions such as AccessControlException. However, note that such servers may fail to log the entire set of exceptions considered critical in the security model for any particular program. Consequently, programs must appropriately log all critical security exceptions beyond those logged by their application server.Note that an IOException remains possible in this compliant example. However, there are few alternatives in the absence of a guarantee that the log file is present. Consequently, this recommendation permits a program to reopen a closed log file. Programs should ensure that the log file is properly protected using operating system level permissions, otherwise an IOException may occur.

Risk Assessment

Exceptions thrown during data logging can cause loss of data and can conceal security problems.

...

\[[API 2006|AA. Bibliography#API 06]\] [Class Logger|http://java.sun.com/javase/6/docs/api/java/util/logging/Logger.html]
\[[JLS 2005|AA. Bibliography#JLS 05]\] [Chapter 11, Exceptions|http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html]
\[[Ware 2008|AA. Bibliography#Ware 08]\]

...

ERR06-J. Do not allow exceptions to expose sensitive information      06. Exceptional Behavior (ERR)      ERR09-J. Prevent inadvertent calls to System.exit() or forced shutdown