Exceptions that are thrown while logging is in progress can prevent successful logging unless special care is taken. Failure to account for exceptions during the logging process can cause security vulnerabilities, including denial of service or vulnerabilities that allow 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 code example writes a critical security exception to the standard error stream. :
Code Block | ||
---|---|---|
| ||
try { // ... } catch (SecurityException se) { System.err.println(ese); // Recover from exception } |
Writing such exceptions to the standard error stream is insufficientinadequate 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 occurs were to occur while writing the security exception, the catch
clause will block would throw an IOException
, and the critical security exception will would be forgottenlost. Finally, an attacker may attempt to disguise the exception so that it occurs with several other innocuous exceptions.
Similarly, using Using Console.printf()
, System.out.print*()
, or eThrowable.printStackTrace()
to output a security exception also constitutes a violation of this guidelinerule.
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 permitted.
Code Block | ||
---|---|---|
| ||
try {
// ...
} catch(SecurityException se) {
logger.log(Level.SEVERE, se);
// Recover from exception
}
|
Typically, only one logger is required for the whole program.
Exceptions
EXC07-EX0: Some application servers such as IBM's WebSphere automatically log critical security exceptions such as AccessControlException
. However, note that such servers may fail to log the entire set of exceptions considered critical in the security model for any particular program. Consequently, programs must appropriately log all critical security exceptions beyond those logged by their application server.
Risk Assessment
Exceptions thrown during data logging can cause loss of data and can conceal security problems.
Rule | Severity | Likelihood | Remediation Cost | Priority | Level |
---|
ERR02-J |
Medium |
Likely |
High | P6 | L2 |
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
CodeSonar |
| JAVA.DEBUG.LOG | Debug Warning (Java) | ||||||
SonarQube |
| S106 | Standard outputs should not be used directly to log anything |
Related Vulnerabilities
Bibliography
Wiki Markup |
---|
\[[API 2006|AA. Bibliography#API 06]\] [Class Logger|http://java.sun.com/javase/6/docs/api/java/util/logging/Logger.html]
\[[JLS 2005|AA. Bibliography#JLS 05]\] [Chapter 11, Exceptions|http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html]
\[[Ware 2008|AA. Bibliography#Ware 08]\] |
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
...
ERR06-J. Do not allow exceptions to expose sensitive information 06. Exceptional Behavior (ERR) ERR09-J. Prevent inadvertent calls to System.exit() or forced shutdown