Page History

If an exception is Exceptions that are thrown while logging is in process, the important data will not be logged progress can prevent successful logging unless special care is taken. This can lead to a multitude of vulnerabilities, either denial of service or ones that allow the Failure to account for exceptions during the logging process can cause security vulnerabilities, such as 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 example errs by defining statements that can throw exceptions while logging is in process. It aims to log a security exception generated within main, however, ends up logging the FileNotFoundException since a careless administrator renamed the log file or a crafty attacker caused the logging mechanism to fail through network tampering. While this code is slightly convoluted, it is easy to fall prey to similar mistakes that can result in an important security exception from not being logged properly. code example writes a critical security exception to the standard error stream:

public class ExceptionLogtry {
  private String logMessage;
  private static Logger theLogger = Logger.getLogger("ExceptionLog.class.getName()");

  public static void main(String[] args// ...
} catch (SecurityException se) {
    ExceptionLog log = new ExceptionLog(System.err.println(se);
    //some Recover securityfrom exception occurs here
    log.logMessage("Security Exception has occurred!");
    log.writeLog(); 
  }
  
  public void logMessage(String message) {
    logMessage = message;
  }
  
  public void writeLog() {
    theLogger.info("Starting to log");      
    try {
          FileReader fr = new FileReader("log_file.txt");  //this can throw an exception and prevent logging 
          BufferedReader br = new BufferedReader(fr);
    }catch (FileNotFoundException fne){ logMessage("File Not Found Exception!"); }
          
    System.err.println(logMessage);    
    //misses writing the original security exception to log file
  }
}

Compliant Solution

}

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 declares all statements that can possibly throw exceptions prior to performing any security critical operations. As a result other exceptions do not interfere with the exceptions that need to be 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 such phenomena. A slightly more expensive alternative is to support recursive logging.

public class ExceptionLog try {
  private static String logMessage;
	
  private static Logger theLogger =
    Logger.getLogger("ExceptionLog.class.getName()");

  public static void main(String[] args// ...
} catch(SecurityException se) {
    ExceptionLog log = new ExceptionLog();
    FileWriter fw=null;
    BufferedWriter bw=null;
    try {
      fw = new FileWriter("log_file.txt");  //this can throw an exception, but security exception is still logged 
      bw = new BufferedWriter(fw);
    }catch (FileNotFoundException fne){ logMessage("File Not Found Exception!"); } 
     catch (IOException e) { logMessage("IO Exception!"); }
          
    //some security exception occurs here
    log.logMessage("Security Exception has occurred!");
    log.writeLog(bw); 
  }
  
  public static void logMessage(String message) {
    logMessage = message;
  }
  
  public void writeLog(BufferedWriter bw) {
    // use the 'least important' type of message, one at
    // the 'finest' level.
    theLogger.info("Starting to log");      
      
    System.err.println(logMessage);    
    //write to a file can miss writing the original security exception 
  }
}

Risk Assessment

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 problems.TODO

Automated Detection

TODO

Related Vulnerabilities

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

References

Automated Detection

Related Vulnerabilities

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 AddedNone