Weakness ID: 404 Vulnerability Mapping:
ALLOWEDThis CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)Abstraction: ClassClass - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource. |
This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.| Scope | Impact | Likelihood |
|---|---|---|
| Availability Other | Technical Impact: DoS: Resource Consumption (Other); Varies by Context Most unreleased resource issues result in general software reliability problems, but if an attacker can intentionally trigger a resource leak, the attacker might be able to launch a denial of service attack by depleting the resource pool. | |
| Confidentiality | Technical Impact: Read Application Data When a resource containing sensitive information is not correctly shutdown, it may expose the sensitive data in a subsequent allocation. |
Phase: Requirements Strategy: 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. |
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 memory in a function. If you allocate memory that you intend to free upon completion of the function, you must be sure to free the memory at all exit points for that function including error conditions. |
Phase: Implementation Memory should be allocated/freed using matching functions such as malloc/free, new/delete, and new[]/delete[]. |
Phase: Implementation When releasing a complex object or structure, ensure that you properly dispose of all of its member components, not just the object itself. |
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
Relevant to the view "Research Concepts" (CWE-1000)| Nature | Type | ID | Name |
|---|---|---|---|
| ChildOf | 664 | Improper Control of a Resource Through its Lifetime | |
| ParentOf | 299 | Improper Check for Certificate Revocation | |
| ParentOf | 459 | Incomplete Cleanup | |
| ParentOf | 763 | Release of Invalid Pointer or Reference | |
| ParentOf | 772 | Missing Release of Resource after Effective Lifetime | |
| ParentOf | 1266 | Improper Scrubbing of Sensitive Data from Decommissioned Device | |
| PeerOf | 405 | Asymmetric Resource Consumption (Amplification) | |
| PeerOf | 239 | Failure to Handle Incomplete Element | |
| CanPrecede | 619 | Dangling Database Cursor ('Cursor Injection') |
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)| Nature | Type | ID | Name |
|---|---|---|---|
| MemberOf | 1003 | Weaknesses for Simplified Mapping of Published Vulnerabilities | |
| ParentOf | 401 | Missing Release of Memory after Effective Lifetime | |
| ParentOf | 459 | Incomplete Cleanup | |
| ParentOf | 763 | Release of Invalid Pointer or Reference | |
| ParentOf | 772 | Missing Release of Resource after Effective Lifetime |
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)| Nature | Type | ID | Name |
|---|---|---|---|
| ParentOf | 401 | Missing Release of Memory after Effective Lifetime | |
| ParentOf | 772 | Missing Release of Resource after Effective Lifetime | |
| ParentOf | 775 | Missing Release of File Descriptor or Handle after Effective Lifetime |
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
Relevant to the view "CISQ Data Protection Measures" (CWE-1340)| Nature | Type | ID | Name |
|---|---|---|---|
| ParentOf | 761 | Free of Pointer not at Start of Buffer | |
| ParentOf | 762 | Mismatched Memory Management Routines | |
| ParentOf | 763 | Release of Invalid Pointer or Reference | |
| ParentOf | 772 | Missing Release of Resource after Effective Lifetime | |
| ParentOf | 775 | Missing Release of File Descriptor or Handle after Effective Lifetime |
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.| Phase | Note |
|---|---|
| Implementation |
This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.Languages
Class: Not Language-Specific (Undetermined Prevalence)
Example 1
The following method never closes the new file handle. Given enough time, the Finalize() method for BufferReader should eventually call Close(), but there is no guarantee as to how long this action will take. In fact, there is no guarantee that Finalize() will ever be invoked. In a busy environment, the Operating System could use up all of the available file handles before the Close() function is called.
The good code example simply adds an explicit call to the Close() function when the system is done using the file. Within a simple example such as this the problem is easy to see and fix. In a real system, the problem may be considerably more obscure.
Example 2
This code attempts to open a connection to a database and catches any exceptions that may occur.
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.
Example 3
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.
Example 4
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.
Example 5
In this example, the program does not use matching functions such as malloc/free, new/delete, and new[]/delete[] to allocate/deallocate the resource.
Example 6
In this example, the program calls the delete[] function on non-heap memory.
| Reference | Description |
|---|---|
Does not shut down named pipe connections if malformed data is sent. | |
Sockets not properly closed when attacker repeatedly connects and disconnects from server. | |
| Ordinality | Description |
|---|---|
Primary | (where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect) Improper release or shutdown of resources can be primary to resource exhaustion, performance, and information confidentiality problems to name a few. |
Resultant | (where the weakness is a quality issue that might indirectly make it easier to introduce security-relevant weaknesses or make them more difficult to detect) Improper release or shutdown of resources can be resultant from improper error handling or insufficient resource tracking. |
Automated Dynamic Analysis This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results. Resource clean up errors might be detected with a stress-test by calling the software simultaneously from a large number of threads or processes, and look for evidence of any unexpected behavior. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results. Effectiveness: Moderate |
Manual Dynamic Analysis Identify error conditions that are not likely to occur during normal usage and trigger them. For example, run the product under low memory conditions, run with insufficient privileges or permissions, interrupt a transaction before it is completed, or disable connectivity to basic network services such as DNS. Monitor the software for any unexpected behavior. If you trigger an unhandled exception or similar error that was discovered and handled by the application's environment, it may still indicate unexpected conditions that were not handled by the application itself. |
Automated Static Analysis Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.) Effectiveness: High |
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.| Nature | Type | ID | Name |
|---|---|---|---|
| MemberOf | 398 | 7PK - Code Quality | |
| MemberOf | 730 | OWASP Top Ten 2004 Category A9 - Denial of Service | |
| MemberOf | 743 | CERT C Secure Coding Standard (2008) Chapter 10 - Input Output (FIO) | |
| MemberOf | 752 | 2009 Top 25 - Risky Resource Management | |
| MemberOf | 857 | The CERT Oracle Secure Coding Standard for Java (2011) Chapter 14 - Input Output (FIO) | |
| MemberOf | 876 | CERT C++ Secure Coding Section 08 - Memory Management (MEM) | |
| MemberOf | 877 | CERT C++ Secure Coding Section 09 - Input Output (FIO) | |
| MemberOf | 882 | CERT C++ Secure Coding Section 14 - Concurrency (CON) | |
| MemberOf | 982 | SFP Secondary Cluster: Failure to Release Resource | |
| MemberOf | 1147 | SEI CERT Oracle Secure Coding Standard for Java - Guidelines 13. Input Output (FIO) | |
| MemberOf | 1162 | SEI CERT C Coding Standard - Guidelines 08. Memory Management (MEM) | |
| MemberOf | 1163 | SEI CERT C Coding Standard - Guidelines 09. Input Output (FIO) | |
| MemberOf | 1306 | CISQ Quality Measures - Reliability | |
| MemberOf | 1308 | CISQ Quality Measures - Security | |
| MemberOf | 1309 | CISQ Quality Measures - Efficiency | |
| MemberOf | 1340 | CISQ Data Protection Measures | |
| MemberOf | 1416 | Comprehensive Categorization: Resource Lifecycle Management |
Usage: ALLOWED-WITH-REVIEW (this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review) |
Reason: Abstraction |
Rationale: This CWE entry is a Class and might have Base-level children that would be more appropriate |
Comments: Examine children of this entry to see if there is a better fit |
| Mapped Taxonomy Name | Node ID | Fit | Mapped Node Name |
|---|---|---|---|
| PLOVER | Improper resource shutdown or release | ||
| 7 Pernicious Kingdoms | Unreleased Resource | ||
| OWASP Top Ten 2004 | A9 | CWE More Specific | Denial of Service |
| CERT C Secure Coding | FIO42-C | CWE More Abstract | Close files when they are no longer needed |
| CERT C Secure Coding | MEM31-C | CWE More Abstract | Free dynamically allocated memory when no longer needed |
| The CERT Oracle Secure Coding Standard for Java (2011) | FIO04-J | Release resources when they are no longer needed | |
| Software Fault Patterns | SFP14 | Failure to release resource |
[REF-44] Michael Howard, David LeBlanc
and John Viega. "24 Deadly Sins of Software Security". "Sin 8: C++ Catastrophes." Page 143. McGraw-Hill. 2010.
|
|
Use of the Common Weakness Enumeration (CWE™) and the associated references from this website are subject to the Terms of Use. CWE is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE). Copyright © 2006–2024, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation. |
||