Page History

The Java garbage collector is called to free unreferenced but as-yet unreleased memory. However, the garbage collector cannot free nonmemory resources such as open file descriptors and database connections. Consequently, failing to release such resources can lead to resource exhaustion attacks. In addition, programs can experience resource starvation while waiting for a finalizer to release resources such as Lock or Semaphore objects. This can occur because Java lacks any temporal guarantee of when finalizers execute other than "sometime before program termination." Finally, output streams may cache object references; such cached objects are not garbage-collected until after the output stream is closed. Consequently, output streams should be closed promptly after use.

A program may leak resources when it relies on finalizers If a program relies on finalize() to release system resources , or if when there is confusion over which part of the program is responsible for releasing system resources, then there exists a possibility for a potential resource leak. In a busy system, there might be a time gap the delay before the finalize() method finalizer is called for an object . An attacker might exploit this vulnerability to provides a window of vulnerability during which an attacker could induce a denial-of-service (DoS) attack. The recommendation OBJ02. Consequently, resources other than raw memory must be explicitly freed in nonfinalizer methods because of the unsuitability of using finalizers. See MET12-J. Avoid using finalizers has more information on the demerits of using finalizers.

The Java garbage collector is called to free up unreleased memory. However, if the program relies on nonmemory resources like file descriptors and database connections, unreleased resources might lead the program to prematurely exhaust its pool of resources. In addition, if the program uses resources like Lock or Semaphore, waiting for finalize() to release the resources may lead to resource starvation. Caching of object references in the output stream also implies that the objects will not be garbage collected unless the streams are closed promptly after use.

On the Windows platform, attempts to delete open files fail silently.

Noncompliant Code Example

This problem is aggravated in the case of database connections. Traditionally, database servers allow a fixed number of connections, which may be dependent on configuration or licensing issues. Not releasing such connections could lead to rapid exhaustion of available connections.

Do not use finalizers for additional reasons to avoid the use of finalizers.

Note that on Windows systems, attempts to delete open files fail silently (see FIO03-J. Remove temporary files before termination for more information).

Noncompliant Code Example (File Handle)

This noncompliant code example opens a file and uses it but fails to explicitly close the file:

public int processFile(String fileName)
                       throws IOException, FileNotFoundException {
  FileInputStream stream = new FileInputStream(fileName);
  BufferedReader bufRead =
      new BufferedReader(new InputStreamReader(stream));
  String line;
  while ((line = bufRead.readLine()) != null) {
    sendLine(line);
  }
  return 1;
}

Compliant Solution

This compliant solution releases all acquired resources, regardless of any exceptions that might occur. Even though dereferencing bufRead might result in an exception, the FileInputStream object is closed as required.

try {
  final FileInputStream stream = new FileInputStream(fileName);
  try {
    final BufferedReader bufRead =
        new BufferedReader(new InputStreamReader(stream));

    String line;
    while ((line = bufRead.readLine()) != null) {
      sendLine(line);
    }
  } finally {
    if (stream != null) {
      try {
        stream.close();
      } catch (IOException e) {
        // Forward to handler
      }
    }
  }
} catch (IOException e) {
  // Forward to handler
}

Compliant Solution (try-with-resources)

This compliant solution uses the try-with-resources statement, introduced in Java SE 7, to release all acquired resources regardless of any exceptions that might occur:

try (FileInputStream stream = new FileInputStream(fileName);
     BufferedReader bufRead =
         new BufferedReader(new InputStreamReader(stream))) {

  String line;
  while ((line = bufRead.readLine()) != null) {
    sendLine(line);
  }
} catch (IOException e) {
  // Forward to handler
}

The try-with-resources construct sends any IOException to the catch clause, where it is forwarded to an exception handler. Exceptions generated during the allocation of resources (that is, the creation of the FileInputStream or BufferedReader), as well as any IOException thrown during execution of the while loop and any IOException generated by closing bufRead or stream, are included.

Noncompliant Code Example (SQL Connection)

The problem of resource pool exhaustion is exacerbated in the case of database connections. Many database servers allow only a fixed number of connections, depending on configuration and licensing. Consequently, failure to release database connections can result in rapid exhaustion of available connections. This noncompliant code example fails to close the connection when an error occurs during execution of the SQL statement or during processing of the results:

public void getResults(String sqlQuery) {
  try {
    Connection conn = getConnection();
    Statement stmt = conn.createStatement();
    ResultSet rs = stmt.executeQuery(sqlQuery);
    processResults(rs);
    stmt.close(); conn.close();
  } catch (SQLException e) { /* Forward to handler */ }
}

In the case above, if an error occurs while executing the statement or while processing the results of the statement, the connection is not closed. A finally block can be used to ensure that the close statements are eventually called.

Noncompliant Code Example

Noncompliant Code Example

This noncompliant code example attempts to address exhaustion of database connections by adding cleanup code in a finally block. However, rs, stmt, or conn could be null, causing the code in the finally block to throw a NullPointerExceptionHowever, while being slightly better, this code is also noncompliant. Both rs and stmt might be null.

Statement stmt = null;
ResultSet rs = null;
Connection conn = getConnection(0);
try {
    stmt = conn.createStatement();
    rs = stmt.executeQuery(sqlQuery);
    processResults(rs);
} catch(SQLException e) {
  // Forward to handler
}
  finally {
    rs.close();
    stmtstmt.close(); conn.close();
}
}

Noncompliant Code Example

Again, while being still better, the code is still noncompliant. This is because rsIn this noncompliant code example, the call to rs.close() or the call to stmt.close() might itself result in throw a SQLException. Consequently, and so stmtconn.close() will is never be called, which violates ERR05-J. Do not let checked exceptions escape from a finally block.

Statement stmt = null;
ResultSet rs = null;
Connection conn = getConnection();
try {
    stmt = conn.createStatement();
    rs = stmt.executeQuery(sqlQuery);
    processResults(rs);
} catch (SQLException e) {
 }
  // Forward to handler
} finally {
  if  if(rs != null) {
      rs.close();
  }
  if  }(stmt != null) {
    stmt.close();
  } if (stmtconn != null) {
      stmt conn.close();
    }
}
}

Compliant Solution

This compliant solution shows how to ensure ensures that resources have been released.are released as required:

Statement stmt = null;
ResultSet rs = null;
Connection conn = getConnection();
try {
    stmt = conn.createStatement();
    rs = stmt.executeQuery(sqlQuery);
    processResults(rs);
} catch (SQLException e) {
 }
   // Forward to handler
} finally {
     try {
    if   if(rs != null) {
        rs.close();}
  } catch (SQLException e)  }{
    // }Forward finallyto (handler
  } finally {
    try {
         if if(stmt != null) {
            stmt.close();}
    } catch (SQLException e) {
    }
  // Forward to handler
    }
 finally {
      finallytry {
        if (conn != null) {conn.close();
        }
      }
}

Noncompliant Code Example

The worst form of noncompliance is not calling methods to release the resource at all. If files are opened, they must be explicitly closed when their work is done.

public int processFile(String fileName) throws IOException, FileNotFoundException catch (SQLException e) {
     FileInputStream stream = new FileInputStream(fileName);
     BufferedReader bufRead = new BufferedReader(new InputStreamReader(stream));// Forward to handler
     String line;}
     while((line=bufRead.readLine()) != null) {
	sendLine(line);
     }
     return 1;}
  }
}

Compliant

...

Solution (try-with-resources)

This compliant code example would release all acquired resources, regardless of any exceptions which might occur. Hence, in the compliant code below, even though bufRead might result in an exception, if a FileInputStream object was instantiated, it will be closed.solution uses the try-with-resources construct, introduced in Java SE 7, to ensure that resources are released as required:

FileInputStream streamtry (Connection conn = nullgetConnection();
BufferedReader bufRead = null;
String line;
try {
  stream = new FileInputStream(fileName Statement stmt = conn.createStatement();
  bufRead = new BufferedReader(new InputStreamReader(stream));
  while((line=bufRead.readLine()) != null) {
	sendLine(line);
  }ResultSet rs = stmt.executeQuery(sqlQuery)) {
  processResults(rs);
} catch (IOExceptionSQLException e) { }
  finally// {
Forward   stream.close();
}

Risk Assessment

to handler
}

The try-with-resources construct sends any SQLException to the catch clause, where it is forwarded to an exception handler. Exceptions generated during the allocation of resources (that is, the creation of the Connection, Statement, or ResultSet), as well as any SQLException thrown by processResults() and any SQLException generated by closing rs, stmt, or conn are included.

Risk Assessment

Failure to explicitly release nonmemory system resources when they are no longer needed can result in Acquiring nonmemory system resources and not releasing them explicitly might lead to resource exhaustion.

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 FIO42-C. Ensure files are properly closed when they are no longer needed.

...

Automated Detection

Although sound automated detection of this vulnerability is not feasible in the general case, many interesting cases can be soundly detected.

Some static analysis tools can detect cases in which there is leak of a socket resource or leak of a stream representing a file or other system resources.

Related Guidelines

...

...

...

\[[API 06|AA. Java References#API 06]\] [Class Object| http://java.sun.com/javase/6/docs/api/java/lang/Object.html]
\[[Goetz 06b|AA. Java References#Goetz 06b]\]
\[[MITRE 09|AA. Java References#MITRE 09]\] [CWE ID 405|http://cwe.mitre.org/data/definitions/405.html] "Asymmetric Resource Consumption (Amplification)", [CWE ID 404|http://cwe.mitre.org/data/definitions/404.html] "Improper Resource Shutdown or Release", [CWE ID 459 |http://cwe.mitre.org/data/definitions/459.html] "Incomplete Cleanup"

Android Implementation Details

The compliant solution (try-with-resources) is not yet supported at API level 18 (Android 4.3).

Bibliography

...

Image Added Image Added Image AddedSER32-J. Do not allow serialization and deserialization to bypass the Security Manager      08. Input Output (FIO)      FIO33-J. Exclude user input from format strings