Sensitive data may be compromised if its lifetime is not limited to the period of its use. An adversary who has control of the file system may be able to access such data if the application
- uses objects to store sensitive data whose contents are not cleared or garbage collected after use
- has memory pages that can be swapped out to disk as required by the operating system (to perform memory management tasks and support hibernation)
- uses a buffer to hold sensitive data (such as
BufferedReader
) that retains copies of the data in the OS cache or in memory - bases its control flow on Reflection that allows circumventing any countermeasures to limit the lifetime of sensitive variables
- reveals sensitive data in debugging messages, log files, environment variables or through thread and core dumps
Currently, complete mitigation requires support from the underlying operating system. For instance, if swapping out of sensitive data is an issue, a secure operating system that disables swapping and hibernation is indispensable.
Noncompliant Code Example
This noncompliant code example reads login information from the console and stores the password as a String
object. The credentials remain exposed until the garbage collector reclaims the memory associated with the String
objects.
class Password { public static void main (String args[]) throws IOException { Console c = System.console(); if (c == null) { System.err.println("No console."); System.exit(1); } String login = c.readLine("Enter your user name: "); String password = c.readLine("Enter your password: "); if (!verify(login, password)) { throw new IOException("Invalid Credentials"); } // ... } // Dummy verify method, always returns true private static final boolean verify(String login, String password) { return true; } }
Compliant Solution
This compliant solution uses the Console.readPassword()
method to obtain the password from the console. This method allows the password to be returned as a sequence of characters as opposed to a String
object. This allows the programmer to clear the password from the array immediately after use. The method also disables echoing of the password to the console.
class Password { public static void main (String args[]) throws IOException { Console c = System.console(); if (c == null) { System.err.println("No console."); System.exit(1); } String login = c.readLine("Enter your user name: "); char [] password = c.readPassword("Enter your password: "); if (!verify(login, password)) { throw new IOException("Invalid Credentials"); } // Clear the password Arrays.fill(password, ' '); } // Dummy verify method, always returns true private static final boolean verify(String login, char[] password) { return true; } }
Noncompliant Code Example
This noncompliant code example uses a BufferedReader
to wrap an InputStreamReader
object so that sensitive data can be read from a file.
BufferedReader br = new BufferedReader(new InputStreamReader( new FileInputStream("file"))); // Read from the file
Compliant Solution
This compliant solution uses a direct allocated NIO buffer to read sensitive data from the file. The data can be cleared immediately after use and is not cached or buffered at multiple locations. It exists only in the system memory.
private void readIntoDirectBuffer() throws IOException { ByteBuffer buffer = ByteBuffer.allocateDirect(16 * 1024); FileChannel rdr = (new FileInputStream("file")).getChannel(); while(rdr.read(buffer) > 0) { // Do something with the buffer buffer.clear(); } rdr.close(); }
Note that manual clearing of the buffer data is mandatory because direct buffers are not subject to garbage collection.
Exceptions
MSC10-EX1: This guideline may be violated if
1. It can be proved that the code is free from other errors that can expose the sensitive data.
2. An attacker does not have physical access to the target machine.
Risk Assessment
Failure to limit the lifetime of sensitive data can lead to information leaks.
Guideline |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
MSC10-J |
medium |
likely |
medium |
P12 |
L1 |
Automated Detection
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this guideline on the CERT website.
Bibliography
[[API 2006]] Class java.nio.ByteBuffer
[[Tutorials 2008]] I/O from the Command Line
[[Sun 2006]] Reading ASCII Passwords From an InputStream Example (JCA Reference Guide)
[[MITRE 2009]] CWE ID 524 "Information Leak Through Caching", CWE ID 528 "Information Leak Through Core Dump Files", CWE ID 215 "Information Leak Through Debug Information", CWE ID 534 "Information Leak Through Debug Log Files", CWE ID 526 "Information Leak Through Environmental Variables" and CWE ID 226 "Sensitive Information Uncleared Before Release"
MSC09-J. Carefully design interfaces before releasing them 49. Miscellaneous (MSC) MSC11-J. Do not assume infinite heap space