Page History

Sensitive data in memory can be vulnerable to compromise. An adversary who can execute code on the same machine as an application 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 (e.g.for example, to perform memory management tasks or to support hibernation).
• holds sensitive data in a buffer (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 countermeasures to limit the lifetime of sensitive variables.
• reveals sensitive data in debugging messages, log files, environment variables, or through thread and core dumps.

Using such attacks to compromise sensitive data becomes harder if the memory containing the data has been cleared. Sensitive data that remains live beyond the minimum period required for its use has an unnecessarily large window of vulnerability. Consequently, programs must minimize the lifetime of sensitive data.

Currently, complete mitigation (that is, complete protection of data in memory) requires support from the underlying operating system and JVMJava Virtual Machine. For instance, if swapping sensitive data out to disk is an issue, a secure operating system that disables swapping and hibernation is required.

...

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

...

This rule may be violated when both of the following are true: 1.

1. It can be proved that the code is free from other errors that can expose the sensitive data

...

1. .

...

1. Attackers lack physical access to the target machine.

Related Guidelines

...

Bibliography

...

...

...