EXC02-J. Prevent exceptions while logging data

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

Noncompliant Code Example

This noncompliant code example errs by using statements that can throw exceptions when logging is in process. It attempts to log a security exception generated within main, however, it will end up logging no messages if 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 not being logged properly.

public class ExceptionLog {

    private String logMessage;

    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() {
        try {
            // This can throw an exception and prevent logging.
            FileWriter fw = new FileWriter("log_file.txt", true);
            BufferedWriter br = new BufferedWriter(fw);
            br.write(logMessage + "\n");
            br.close();
        } catch (FileNotFoundException fnf){ logMessage("File Not Found Exception!"); }
        catch(IOException ie) { logMessage("IO Exception!"); }          
        System.err.println(logMessage);    
        // No log message is written to the file in the event of an exception.
    }
}

Compliant Solution

This compliant solution executes several statements that can possibly throw exceptions prior to performing any security critical operations and allows writeLog() to throw an exception back to the caller in the event of a problem writing to the log file. As a result, exceptions do not result in the silent 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 such phenomena.

public class ExceptionLog {
    
    private static String logMessage;
    
    public static void main(String[] args) {
        ExceptionLog log = new ExceptionLog();
        FileWriter fw=null;
        BufferedWriter bw=null;
        try {
            fw = new FileWriter("log_file.txt", true);  
            // This can throw an exception, but the logging of messages is
            // not silently prevented.
            bw = new BufferedWriter(fw);
        }
        catch (IOException e) { 
            // The logging example cannot recover from failure to open
            // the log file.
            throw new RuntimeException(e);
        }
        
        //some security exception occurs here
        try {
            log.logMessage("Security Exception has occurred!");
            log.writeLog(bw);
        }
        catch (IOException e) {
            // Logging of the security exception does not silently fail.
            System.err.println("Logging error failed.");
        }
        
        try {
            bw.close();
        }
        catch (IOException e) {
            System.err.println("Closing log file failed.");
        }
    }
    
    public static void logMessage(String message) {
        logMessage = message;
    }
    
    public void writeLog(BufferedWriter bw) throws IOException {
        bw.write(logMessage + "\n");
        System.err.println(logMessage);    
    }
}

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 an IOException is possible, there is little that can be done 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	medium	likely	high	P6	L2

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 11. Exceptional Behavior (EXC) EXC03-J. Try to recover gracefully from system errors

Space shortcuts

Page tree