Page History

If an exception is Exceptions that are thrown while logging is in progress , data may not be logged can prevent successful logging unless special care is taken. Failing Failure to account for exceptions during the logging process can result in a multitude of causes security vulnerabilities, such as including denial of service or vulnerabilities that allow the 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.

Noncompliant Code Example

This noncompliant code example uses statements that can throw exceptions when while logging is in progressunderway. It attempts to log a SecurityException generated within the run() method. However, however, the original log message is not logged if in the event of an exception is thrown while logging is underway, the original log message is lost.

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 + "\n").getBytes());
    } 

    // If an exception is caught, the original log message to log is lost
    catch (FileNotFoundException e){
      logMessage("File Not Found Exception."); 
    }
    catch(IOException e) {
      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 RuntimeException(e);
      }
    }
  }

  public void run() {
    try {
      // Some 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 if when there is a problem with the application's file system or if when a thread attempts to write to the log file when the file while it is locked by another thread. An attacker can exploit these problems this code by:

• Gaining access to the application's file system and inducing a runtime exception by deleting or changing the permissions of the log file so that a runtime exception results. While this appears to be inconceivable. Although such attacker access appears unlikely, it is possible that an attacker has could have access to the physical media from which the application reads data. If the application's code depends on such functionalityIn this case, an attacker may can induce runtime exceptions at the appropriate moment to circumvent logging. This vulnerability can particularly manifest in multi-threaded applications..
• Providing Exploiting the multi-threaded nature of the application by providing input to the application via normal input channels so that log messages are lost as a result of an OverlappingFileLockException. Because this attack vector makes use of standard input channels to perform the attack, it causes multiple threads to attempt to log messages simultaneously. This attack exploits the multi-threaded nature of the application to induce {{OverlappingFileLockException}}s that cause exception logging to fail. This attack vector is much simpler to implement than the previous attack , which requires because it makes use of standard input channels rather than requiring access to the application's file system.

Compliant Solution

This compliant solution executes several statements that can possibly throw exceptions prior to performing any security critical operations and 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 EXC03-J. Use a logging API to log critical security exceptions for more information on the use of logging libraries. )

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
    // 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);
    }
  }    
}

As a result, exceptions do not result in In this compliant solution, exceptions cannot cause either failure to log a message or logging a different message than the was intended one. While Although this is a stringent requirement, it is necessary in cases where an an exception attacker can be deliberately thrown attempt to conceal an attacker's trackshis tracks by inducing throwing of an exception. The logging mechanism must be robust and should be able to detect and handle all such cases. A Support for recursive logging is also an acceptable solution, but is slightly more expensive alternative is to support recursive loggingimplement.

While Note that an IOException remains possible in this compliant solution an IOException is still possible, there is little that can be done when writing the data to the log file if the existence of the file itself is under questionexample. However, there are few alternatives in the absence of a guarantee that the log file is present. Consequently, this recommendation does not prevent permits a program from reopening to reopen a closed log file. If an IOException results when doing so, it is likely Programs should ensure that the log file was not is properly protected using operating system level permissions, otherwise an IOException may occur.

Risk Assessment

If an exception is thrown while data is being logged, the data may be lost or security problems may be concealedExceptions thrown during data logging can cause loss of data and can conceal security problems.

Automated Detection

...

Related Vulnerabilities

HARMONY-5981

...