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. This can result in a multitude of Failure to account for exceptions during the logging process can cause security vulnerabilities, such as denial of service or vulnerabilities that allow the allowing 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 logging is in process. It attempts to log a SecurityException generated within the run() method, however, the original log message is not logged if an exception is thrown during the logging process. An exception is thrown if there is a problem with the application's file system or if a thread attempts to write to the log file when the file is locked by another thread. An attacker can exploit these problems by:

• Gaining access to the application's file system and deleting or changing the permissions of the log file.
• Exploiting the multi-threaded nature of the application by providing input to the application via normal input channels that results in log messages being lost due to an OverlappingFileLockException. Because this attack vector makes use of standard input channels to perform the attack, it is much simpler to implement than the previous attack, which requires access to the application's file system.

writes a critical security exception to the standard error stream:

try {
  // ...
} catch (SecurityException se) {
  

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(messagese);
  // Recover   fo.write((message + "\n").getBytes());
    } 

    // If an exception is caught, the original 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();
    }
  }    
}

Compliant Solution

from exception
}

Writing such exceptions to the standard error stream is inadequate for logging purposes. First, the standard error stream may be exhausted or closed, 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 were to occur while writing the security exception, the catch block would throw an IOException and the critical security exception would be lost. Finally, an attacker may disguise the exception so that it occurs with several other innocuous exceptions.

Using Console.printf(), System.out.print*(), or Throwable.printStackTrace() to output a security exception also constitutes a violation of this rule.

Compliant Solution

This compliant solution uses java.util.logging.Logger, the default logging API provided by JDK 1.4 and later. Use of other compliant logging mechanisms, such as log4j, is also permittedThis 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 Logger class to implement logging (see EXC08-J. Use a logging API to log critical security exceptions for more information on the use of logging libraries). As a result, exceptions do not result in failure to log a message or a different message than intended being logged. While this is a stringent requirement, it is necessary in cases where an exception can be deliberately thrown to conceal an attacker's tracks. The logging mechanism must be robust and should be able to detect and handle all such cases.

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

  public ExceptionLog(Integer i, Logger l) {
    logger = l;
    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);
    }
  }    
}

A slightly more expensive alternative is to support recursive logging.

Note that this recommendation does not prevent a program from reopening a closed log file after it realizes that important data must be captured.

While 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 question.

Risk Assessment

try {
  // ...
} catch(SecurityException se) {
  logger.log(Level.SEVERE, se);
  // Recover from exception
}

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

Risk Assessment

Exceptions thrown during data logging can cause loss of data and can conceal security problemsIf an exception is thrown while data is being logged then data may be lost or problems may be concealed.

Automated Detection

...

Tool	Version	Checker	Description
CodeSonar	Include Page CodeSonar_V CodeSonar_V	JAVA.DEBUG.LOG	Debug Warning (Java)
SonarQube	Include Page SonarQube_V SonarQube_V	S106	Standard outputs should not be used directly to log anything

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

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

HARMONY-5981 describes a vulnerability in the HARMONY implementation of Java. In this implementation, the FileHandler class can receive log messages, but if one thread closes the associated file, a second thread will throw an exception when it tries to log a message.

Bibliography

...

Image Added Image Added Image AddedEXC01-J. Do not allow exceptions to transmit sensitive information      13. Exceptional Behavior (EXC)      EXC03-J. Try to gracefully recover from system errors