Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Printing the stack trace can also result in unintentionally leaking information about the structure and state of the process to an attacker. If a Java program is run within a console, and it terminates because of an uncaught exception, the exception's message and stack trace are displayed on the console; the stack trace may itself leak sensitive information about the program's internal structure. Consequently, command-line programs must never abort because of an uncaught exception.

Noncompliant Code Example (Leaks from Exception Message and Type)

In this noncompliant code example, the program that must read a file supplied by the user but the contents and layout of the file system are sensitive. The program accepts a file name as an input argument but fails to prevent any resulting exceptions from being presented to the user.

...

When a requested file is absent, the FileInputStream constructor throws a FileNotFoundException allowing an attacker to reconstruct the underlying file system by repeatedly passing fictitious path names to the program.

Noncompliant Code Example (Wrapping and Rethrowing Sensitive Exception)

This noncompliant code example logs the exception and wraps it in a more general exception before re-throwing it.

...

Even if the logged exception is not accessible to the user, the original exception is still informative and can be used by an attacker to discover sensitive information about the file system layout.

Noncompliant Code Example (Sanitized Exception)

This noncompliant code example logs the exception and throws a custom exception that does not wrap the FileNotFoundException.

...

While this exception is less likely to leak useful information than previous noncompliant code examples, it still reveals that the specified file cannot be read. More specifically, the program reacts differently to nonexistent file paths than it does to valid ones, and an attacker can still infer sensitive information about the file system from this program's behavior. Failure to restrict user input leaves the system vulnerable to a brute force attack in which the attacker discovers valid file names by issuing queries that collectively cover the space of possible file names. Filenames that cause the program to return the sanitized exception indicate nonexistent files, filenames that don't, reveal existing files.

Compliant Solution (Canonicalization)

This compliant solution implements the policy that only files that live in c:\homepath may be opened by the user, and that the user is not allowed to discover anything about files outside this directory. The solution issues a terse error message if the file cannot be opened, or the file does not live in the proper directory. This serves to conceal any information about files outside c::\homepath.

...

Code Block
bgColor#ccccff
class ExceptionExample {
  public static void main(String[] args) {
    File file = null;
    try {
      file = new File(System.getenv("APPDATA") + args[0]).getCanonicalFile();
      if (!file.getPath().startsWith("c:\\homepath")) {
        System.out.println("Invalid file");
        return;
      }
    } catch (IOException x) {
      System.out.println("Invalid file");
      return;
    }

    try {
      FileInputStream fis = new FileInputStream(file);
    } catch (FileNotFoundException x) {
      System.out.println("Invalid file");
      return;
    }
  }
}

Compliant Solution (Restricted Input)

This compliant solution operates under the policy that only c:\homepath\file1 and c:\homepath\file2 are permitted to be opened by the user.

...

For scalablity, the switch statement should be replaced with some sort of mapping from integers to valid file names, or at least an enum type representing valid files.

Risk Assessment

Exceptions may inadvertently reveal sensitive information unless care is taken to limit the information disclosure.

Recommendation

Severity

Likelihood

Remediation Cost

Priority

Level

ERR06-J

medium

probable

high

P4

L3

Related Vulnerabilities

CVE-2009-2897

Other Languages

This rule appears in the C++ Secure Coding Standard as ERR12-CPP. Do not allow exceptions to transmit sensitive information.

Related Guidelines

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="499cc4601a478046-47abbdc9-4dec47d6-9f33b335-05e4fa354accda1985d4df5c"><ac:plain-text-body><![CDATA[

[[MITRE 2009

AA. Bibliography#MITRE 09]]

[CWE ID 209

http://cwe.mitre.org/data/definitions/209.html] "Information Exposure Through an Error Message"

]]></ac:plain-text-body></ac:structured-macro>

 

CWE ID 600 "Uncaught Exception in Servlet"

 

CWE ID 497 "Exposure of System Data to an Unauthorized Control Sphere"

Bibliography

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="649f6af43077fb4d-5adfbdd7-447e4fe5-85b08dd3-d194e8b8302a64bbe763f551"><ac:plain-text-body><![CDATA[

[[Gong 2003

AA. Bibliography#Gong 03]]

9.1 Security Exceptions

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="ddecffe500402d5a-03453d0a-496d4a6e-82488af5-e411ab6eb42856947b4d8c83"><ac:plain-text-body><![CDATA[

[[SCG 2007

AA. Bibliography#SCG 07]]

Guideline 3-4 Purge sensitive information from exceptions

]]></ac:plain-text-body></ac:structured-macro>

...