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 finalize()
to release resources such as Lock
or Semaphore
objects. This can occur because Java lacks any temporal guarantee of when finalize()
methods 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 finalize()
to release system resources or when there is confusion over which part of the program is responsible for releasing system resources. In a busy system, the delay before the finalize()
method is called for an object provides a window of vulnerability during which an attacker could induce a DoS attack. Consequently, resources other than raw memory must be explicitly freed in nonfinalizer methods because of the unsuitability of using finalizers. See the rule MET12-J. 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 rule 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 (Java SE 7: 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. This includes exceptions generated during the allocation of resources (that is, the creation of the FileInputStream
or BufferedReader
). It also includes any IOException
thrown during execution of the while
loop. Finally, it includes any IOException
generated by closing bufRead
or stream
.
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 */ } }
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 NullPointerException
.
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 { rs.close(); stmt.close(); conn.close(); }
Noncompliant Code Example
In this noncompliant code example, the call to rs.close()
or the call to stmt.close()
might throw a SQLException
. Consequently, conn.close()
is never called. This is a violation of rule 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 (rs != null) { rs.close(); } if (stmt != null) { stmt.close(); } if (conn !=null) { conn.close(); } }
Compliant Solution
This compliant solution ensures that resources 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 (rs != null) {rs.close();} } catch (SQLException e) { // forward to handler } finally { try { if (stmt != null) {stmt.close();} } catch (SQLException e) { // forward to handler } finally { try { if (conn != null) {conn.close();} } catch (SQLException e) { // forward to handler } } } }
Compliant Solution (Java SE 7: try-with-resources)
This compliant solution uses the try-with-resources construct, introduced in Java SE 7, to ensure that resources are released as required.
try (Connection conn = getConnection(); Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery(sqlQuery)) { processResults(rs); } catch (SQLException e) { // forward to handler }
The try-with-resources construct sends any SQLException
to the catch
clause, where it is forwarded to an exception handler. This includes exceptions generated during the allocation of resources (that is, the creation of the Connection
, Statement
, or ResultSet
). It also includes any SQLException
thrown by processResults()
. Finally, it includes any SQLException
generated by closing rs
, stmt
, or conn
.
Risk Assessment
Failure to explicitly release nonmemory system resources when they are no longer needed can result in resource exhaustion.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
FIO04-J |
low |
probable |
medium |
P4 |
L3 |
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 where there is leak of a socket resource or leak of a stream representing a file or other system resources.
Related Guidelines
FIO42-C. Ensure files are properly closed when they are no longer needed |
|
FIO42-CPP. Ensure files are properly closed when they are no longer needed |
|
CWE-404. Improper resource shutdown or release |
|
|
CWE-459. Incomplete cleanup |
|
CWE-770. Allocation of resources without limits or throttling |
|
CWE-405. Asymmetric resource consumption (amplification) |
Bibliography
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="24996638-9922-4ce1-ad5d-61be2dc7a48e"><ac:plain-text-body><![CDATA[ |
[[API 2006 |
AA. References#API 06]] |
[Class |
http://java.sun.com/javase/6/docs/api/java/lang/Object.html] |
]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="1f47a98c-3095-4789-8bd0-60a91d74f4c3"><ac:plain-text-body><![CDATA[ |
[[Goetz 2006b |
AA. References#Goetz 06b]] |
|
]]></ac:plain-text-body></ac:structured-macro> |
|
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="299425b6-72a3-407d-b4a9-2bd6ef62ac18"><ac:plain-text-body><![CDATA[ |
[[J2SE 2011 |
AA. References#J2SE 11]] |
The try-with-resources Statement |
]]></ac:plain-text-body></ac:structured-macro> |
12. Input Output (FIO) FIO05-J. Do not expose buffers created using the wrap() or duplicate() methods to untrusted code