EXC02-J. Prevent exceptions while logging data

If an exception is thrown while logging is in process, the important data will not be logged unless special care is taken. This can lead to a multitude of vulnerabilities, either denial of service or ones that allow the attacker to conceal critical security exceptions by preventing them from being logged.

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.

import java.util.logging.Logger;
import java.io.FileReader;
import java.io.BufferedReader;
import java.io.FileNotFoundException;

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

  public static void main(String[] args) {
    ExceptionLog log = new ExceptionLog();
    //some security 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

This 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.

import java.util.logging.Logger;
import java.io.BufferedWriter;
import java.io.FileWriter;
import java.io.FileNotFoundException;
import java.io.IOException;

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

  public static void main(String[] args) {
    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 
  }
}

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 an IOException is possible, there is little one can do when writing the data to the log file is itself under question.

Risk Assessment

If an exception is thrown while data is being logged then data may be lost or problems may be concealed.

Rule	Severity	Likelihood	Remediation Cost	Priority	Level
EXC02-J	low	unlikely	high	P1	L3

Automated Detection

TODO

Related Vulnerabilities

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

References

[[API 06]] Class Logger
[[JLS 05]] Chapter 11, Exceptions

EXC01-J. Do not allow exceptions to transmit sensitive information 10. Exceptional Behavior (EXC) EXC03-J. Try to recover gracefully from system errors

Space shortcuts

Page tree