MSC11-J. Do not assume infinite heap space

A Java OutofMemoryError occurs if the program attempts to use more heap space than what is available. Among other causes, this error may result from

• a memory leak
• an infinite loop
• limited amounts of default heap memory available
• incorrect implementation of common data structures (hash tables, vectors and so on)
• unbound deserialization
• writing a large number of objects to an ObjectOutputStream
• creating a large number of threads

Noncompliant Code Example (readLine())

This noncompliant code example places no upper bounds on the memory space required to execute the program. Consequently, the program can easily exhaust the available heap space.

public class ShowHeapError {
  Vector<String> names = new Vector<String>();
  InputStreamReader input = new InputStreamReader(System.in);
  BufferedReader reader = new BufferedReader(input);

  public void addNames() throws IOException {
    String newName;
    do {     
      // Adding unknown number of records to a list; user can exhaust the heap
      newName = reader.readLine();    
      names.addElement(newName);      
    } while(newName.equalsIgnoreCase("quit") == false); // Enter "quit" to quit the program
    // Close "reader" and "input"
  }

  public static void main(String[] args) throws IOException {
    ShowHeapError demo = new ShowHeapError();
    demo.addNames();
  }
}

According to the Java API [[API 2006]], BufferedReader.readLine() method documentation

[readLine()] Reads a line of text. A line is considered to be terminated by any one of a line feed ('\n'), a carriage return ('\r'), or a carriage return followed immediately by a linefeed.

Any code that uses this method is susceptible to abuse because the user can enter a string of any length. This does not require the noncompliant code example to read input using a loop.

Compliant Solution (Use Databases)

If the objects or data structures are large enough to potentially cause heap exhaustion, the programmer must consider using databases instead.

To remedy the noncompliant code example, the user can reuse a single long variable to store the input and write that value into a database containing a table User, with a field userID along with any other required fields. This prevents the heap from being exhausted.

Noncompliant Code Example

In a server-class machine using a parallel garbage collector, the default initial and maximum heap sizes are as follows for J2SE 6.0 [[Sun 2006]]:

• initial heap size: larger of 1/64th of the machine's physical memory on the machine or some reasonable minimum
• maximum heap size: smaller of 1/4th of the physical memory or 1GB

This noncompliant code example requires more memory on the heap than is available by default.

/** Assuming the heap size as 512 MB (calculated as 1/4th of 2 GB RAM = 512 MB)
 *  Considering long values being entered (64 bits each, the max number of elements
 *  would be 512 MB/64bits = 67108864)
 */
public class ShowHeapError {
   Vector<Long> names = new Vector<Long>(); // Accepts unknown number of records
   long newID = 0L;
   int count = 67108865;
   int i = 0;
   InputStreamReader input = new InputStreamReader(System.in);
   Scanner reader = new Scanner(input);

   public void addNames(){
     do{
       // Adding unknown number of records to a list
       // The user can enter more IDs than the heap can support and thus 
       // exhaust the heap. Assume that the record ID is a 64 bit long value
      
       System.out.print("Enter recordID (To quit, enter -1): ");
       newID = reader.nextLong();
       
       names.addElement(newID);
       i++;
     }while (i < count || newID != -1);
     // Close "reader" and "input"
   }

   public static void main(String[] args) {
     ShowHeapError demo = new ShowHeapError();
     demo.addNames();
   }
}

Compliant Solution

The OutOfMemoryError can be avoided by ensuring that the absence of infinite loops, memory leaks, and unnecessary object retention. When memory requirements are known ahead of time, the heap size can be tailored to fit the requirements using the following runtime parameters [[Java 2006]]:

java -Xms<initial heap size> -Xmx<maximum heap size>

For example,

java -Xms128m -Xmx512m ShowHeapError

Here the initial heap size is set to 128 MB and the maximum heap size to 512 MB.

This setting can be changed either using the Java Control Panel or from the command line. It cannot be adjusted through the application itself.

Noncompliant Code Example

According to the Java API [[API 2006]], Class ObjectInputStream documentation

ObjectOutputStream and ObjectInputStream can provide an application with persistent storage for graphs of objects when used with a FileOutputStream and FileInputStream respectively. ObjectInputStream is used to recover the objects previously serialized. Other uses include passing objects between hosts using a socket stream or for marshaling and unmarshaling arguments and parameters in a remote communication system.

By design, objects are written to the stream only on their first appearance therein. For subsequent appearances, the stream writes a handle to the earlier appearance of the object. The ObjectOutputStream maintains a table that maps previously-written objects to their corresponding handles. This table remains live until the stream is closed; consequently, it prevents garbage collection of previously-written objects. This can cause an OutOfMemoryError when streams remain open for extended durations.

FileOutputStream fos = new FileOutputStream("data.txt");
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(new Date());
// ... 

Compliant Solution

Make judicious use of the ObjectOutputStream.reset() method to clear references to previously written objects and consequently permit them to be garbage collected. Note that this will cause subsequent writes of a previously-written object to be treated as though they were the initial write, leading to multiple copies of the object in the serialized data stream. This issue must be addressed to enable correct program operation.

FileOutputStream fos = new FileOutputStream("data.txt");
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(new Date());
oos.reset();  // Reset the Object-Handle table to its initial state
// ... 

Risk Assessment

Assuming that infinite heap space is available can result in denial of service.

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website

Other Languages

This rule appears in the C Secure Coding Standard as MEM11-C. Do not assume infinite heap space.

This rule appears in the C++ Secure Coding Standard as MEM12-CPP. Do not assume infinite heap space.

Related Vulnerabilities

GERONIMO-4224

Bibliography

[[Sun 2006]] Garbage Collection Ergonomics, "Default values for the Initial and Maximum heap size"
[[Java 2006]] java - the Java application launcher, "Syntax for increasing the heap size"
[[Sun 2003]] Chapter 5: Tuning the Java Runtime System, Tuning the Java Heap
[[API 2006]] Class ObjectInputStream and ObjectOutputStream
[[SDN 2008]] Serialization FAQ
[[MITRE 2009]] CWE-400 "Uncontrolled Resource Consumption (aka 'Resource Exhaustion')," CWE-770, "Allocation of Resources Without Limits or Throttling"

MSC10-J. Limit the lifetime of sensitive data      49. Miscellaneous (MSC)      MSC12-J. Prefer using Iterators over Enumerations