The software does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed. When a resource is not released after use, it can allow attackers to cause a denial of service. 900 Category ChildOf 867 800 Category ChildOf 808 1000 Weakness ChildOf 404 1000 Weakness ChildOf 400 868 Category ChildOf 882 888 Category ChildOf 892 "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. Architecture and Design Implementation Medium to High Availability DoS: resource consumption (other) When allocating resources without limits, an attacker could prevent all other processes from accessing the same type of resource. Requirements Language Selection Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, languages such as Java, Ruby, and Lisp perform automatic garbage collection that releases memory for objects that have been deallocated. 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. Operation Architecture and Design Limit Resource Consumption Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems. 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. Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703). The following code attempts to process a file by reading it in line by line until the end has been reached. Java private void processFile(string fName) { BufferReader in = new BufferReader(new FileReader(fName)); String line; while ((line = in.ReadLine()) != null) { processLine(line); } } 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. 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. C# SqlConnection conn = new SqlConnection(connString); SqlCommand cmd = new SqlCommand(queryString); cmd.Connection = conn; conn.Open(); SqlDataReader rdr = cmd.ExecuteReader(); HarvestResults(rdr); conn.Connection.Close(); 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. The following method never closes the file handle it opens. The Finalize() method for StreamReader 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. Java private void processFile(string fName) { StreamWriter sw = new StreamWriter(fName); string line; while ((line = sr.ReadLine()) != null) processLine(line); } If an exception occurs after establishing the database connection and before the same connection closes, the pool of database connections may become exhausted. If the number of available connections is exceeded, other users cannot access this resource, effectively denying access to the application. Using the following database connection pattern will ensure that all opened connections are closed. The con.close() call should be the first executable statement in the finally block. Java try { Connection con = DriverManager.getConnection(some_connection_string) } catch ( Exception e ) { log( e ) } finally { con.close() } Under normal conditions the following C# code executes a database query, processes the results returned by the database, and closes the allocated SqlConnection object. But 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. C# ... SqlConnection conn = new SqlConnection(connString); SqlCommand cmd = new SqlCommand(queryString); cmd.Connection = conn; conn.Open(); SqlDataReader rdr = cmd.ExecuteReader(); HarvestResults(rdr); conn.Connection.Close(); ... The following C function does not close the file handle it opens if an error occurs. If the process is long-lived, the process can run out of file handles. C int decodeFile(char* fName) { char buf[BUF_SZ]; FILE* f = fopen(fName, "r"); if (!f) { printf("cannot open %s\n", fName); return DECODE_FAIL; } else { while (fgets(buf, BUF_SZ, f)) { if (!checkChecksum(buf)) { return DECODE_FAIL; } else { decodeBlock(buf); } } } fclose(f); return DECODE_SUCCESS; } In this example, the program does not use matching functions such as malloc/free, new/delete, and new[]/delete[] to allocate/deallocate the resource. C++ class A { void foo(); }; void A::foo(){ int *ptr; ptr = (int*)malloc(sizeof(int)); delete ptr; } In this example, the program calls the delete[] function on non-heap memory. C++ class A{ void foo(bool); }; void A::foo(bool heap) { int localArray[2] = { 11,22 }; int *p = localArray; if (heap){ p = new int[2]; } delete[] p; } CVE-2007-0897 Chain: anti-virus product encounters a malformed file but returns from a function without closing a file descriptor (CWE-775) leading to file descriptor consumption (CWE-400) and failed scans. CVE-2001-0830 Sockets not properly closed when attacker repeatedly connects and disconnects from server. CVE-1999-1127 Does not shut down named pipe connections if malformed data is sent. CVE-2009-2858 Chain: memory leak (CWE-404) leads to resource exhaustion. CVE-2009-2054 Product allows exhaustion of file descriptors when processing a large number of TCP packets. CVE-2008-2122 Port scan triggers CPU consumption with processes that attempt to read data from closed sockets. CVE-2007-4103 Product allows resource exhaustion via a large number of calls that do not complete a 3-way handshake. CVE-2002-1372 Return values of file/socket operations not checked, allowing resultant consumption of file descriptors. 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. Use lock classes for mutex management CON02-CPP 469 2009-05-13 CWE Content Team MITRE 2010-02-16 updated Demonstrative_Examples, Potential_Mitigations, Relationships CWE Content Team MITRE 2010-04-05 updated Potential_Mitigations CWE Content Team MITRE 2010-06-21 updated Potential_Mitigations CWE Content Team MITRE 2011-06-01 updated Common_Consequences, Relationships, Taxonomy_Mappings CWE Content Team MITRE 2011-06-27 updated Observed_Examples, Related_Attack_Patterns, Relationships CWE Content Team MITRE 2011-09-13 updated Relationships, Taxonomy_Mappings CWE Content Team MITRE 2012-05-11 updated Demonstrative_Examples, Relationships, Taxonomy_Mappings CWE Content Team MITRE 2012-10-30 updated Potential_Mitigations