Missing Release of Resource after Effective Lifetime
Weakness ID: 772 (Weakness Base)Status: Incomplete
+ Description

Description Summary

The software does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.

Extended Description

When a resource is not released after use, it can allow attackers to cause a denial of service.

+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Common Consequences

When allocating resources without limits, an attacker could prevent all other processes from accessing the same type of resource.

+ Likelihood of Exploit

Medium to High

+ Demonstrative Examples

Example 1

The following code attempts to process a file by reading it in line by line until the end has been reached.

(Bad Code)
Example Language: Java 
private void processFile(string fName)
BufferReader in = new BufferReader(new FileReader(fName));
string line;
while ((line = in.ReadLine()) != null)

The problem with the above code is that it never closes the file handle it opens. The Finalize() method for BufferReader eventually calls Close(), but there is no guarantee as to how long it will take before the Finalize() method is invoked. In fact, there is no guarantee that Finalize() will ever be invoked. In a busy environment, this can result in the VM using up all of its available file handles.

Example 2

The following code attempts to open a new connection to a database, process the results returned by the database, and close the allocated SqlConnection object.

(Bad Code)
Example Language: C# 
SqlConnection conn = new SqlConnection(connString);
SqlCommand cmd = new SqlCommand(queryString);
cmd.Connection = conn;
SqlDataReader rdr = cmd.ExecuteReader();

The problem with the above code is that if an exception occurs while executing the SQL or processing the results, the SqlConnection object is not closed. If this happens often enough, the database will run out of available cursors and not be able to execute any more SQL queries.

+ Potential Mitigations

Phase: Requirements

Strategy: Language Selection

Use a language with features that can automatically mitigate or eliminate resource-shutdown weaknesses.

For example, languages such as Java, Ruby, and Lisp perform automatic garbage collection that releases memory for objects that have been deallocated.

Phase: Implementation

It is good practice to be responsible for freeing all resources you allocate and to be consistent with how and where you free resources in a function. If you allocate resources that you intend to free upon completion of the function, you must be sure to free the resources at all exit points for that function including error conditions.

Phase: Implementation

For system resources, consider using the getrlimit() function included in the sys/resources library in order to determine how many resources are currently allowed to be opened for the process.

When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.

(Good Code)
Example Language:
#include <sys/resource.h>
int return_value;
struct rlimit rlp;
return_value = getrlimit(RLIMIT_NOFILE, &rlp);

Phase: Operation

Use resource-limiting settings provided by the operating system or environment. For example, setrlimit() can be used to set limits for certain types of resources. However, this is not available on all operating systems.

Ensure that your application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness BaseWeakness Base400Uncontrolled Resource Consumption ('Resource Exhaustion')
Research Concepts1000
ChildOfWeakness BaseWeakness Base404Improper Resource Shutdown or Release
Research Concepts (primary)1000
ChildOfCategoryCategory8082010 Top 25 - Weaknesses On the Cusp
Weaknesses in the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors (primary)800
ParentOfWeakness BaseWeakness Base401Failure to Release Memory Before Removing Last Reference ('Memory Leak')
Research Concepts (primary)1000
ParentOfWeakness VariantWeakness Variant775Missing Release of File Descriptor or Handle after Effective Lifetime
Research Concepts (primary)1000
+ Theoretical Notes

Vulnerability theory is largely about how behaviors and resources interact. "Resource exhaustion" can be regarded as either a consequence or an attack, depending on the perspective. This entry is an attempt to reflect one of the underlying weaknesses that enable these attacks (or consequences) to take place.

+ Maintenance Notes

"Resource exhaustion" (CWE-400) is currently treated as a weakness, although it is more like a category of weaknesses that all have the same type of consequence. While this entry treats CWE-400 as a parent in view 1000, the relationship is probably more appropriately described as a chain.

+ Content History
Submission DateSubmitterOrganizationSource
2009-05-13Internal CWE Team