Missing Release of Resource after Effective LifetimeID: 772 | Date: (C)2012-05-14 (M)2022-10-10 |
Type: weakness | Status: INCOMPLETE |
Abstraction Type: Base |
Description
The software does not release a resource after its effective
lifetime has ended, i.e., after the resource is no longer
needed.
Extended DescriptionWhen a resource is not released after use, it can allow attackers to cause
a denial of service.
Likelihood of Exploit: Medium to High
Applicable PlatformsNone
Time Of Introduction
- Architecture and Design
- Implementation
Related Attack Patterns
Common Consequences
Scope | Technical Impact | Notes |
---|
Availability | DoS: resource consumption
(other) | When allocating resources without limits, an attacker could prevent
all other processes from accessing the same type of resource. |
Detection MethodsNone
Potential Mitigations
Phase | Strategy | Description | Effectiveness | Notes |
---|
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. | | |
OperationArchitecture 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). | | |
Relationships
Related CWE | Type | View | Chain |
---|
CWE-772 ChildOf CWE-892 | Category | CWE-888 | |
Demonstrative Examples (Details)
- 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. (Demonstrative Example Id DX-82)
- In this example, the program calls the delete[] function on non-heap
memory. (Demonstrative Example Id DX-86)
- In this example, the program does not use matching functions such as
malloc/free, new/delete, and new[]/delete[] to allocate/deallocate the
resource. (Demonstrative Example Id DX-85)
- 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. (Demonstrative Example Id DX-84)
- 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.
- The following code attempts to process a file by reading it in line
by line until the end has been reached.
- 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. (Demonstrative Example Id DX-81)
- 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. (Demonstrative Example Id DX-83)
Observed Examples
- 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.
For more examples, refer to CVE relations in the bottom box.
White Box Definitions None
Black Box Definitions None
Taxynomy Mappings
Taxynomy | Id | Name | Fit |
---|
CERT C++ Secure Coding | CON02-CPP | Use lock classes for mutex management | |
References:None