CWE

Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > CWE- Individual Dictionary Definition (3.0)  
ID

CWE-672: Operation on a Resource after Expiration or Release

Weakness ID: 672
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.
+ Relationships

The table(s) below 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 "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory3617PK - Time and State
ParentOfBaseBase825Expired Pointer Dereference
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and Design
Implementation
Operation
+ Applicable Platforms
The listings below show 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

(Language-Independent classes): (Undetermined Prevalence)

Paradigms

Mobile: (Undetermined Prevalence)

+ Common Consequences

The table below 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.

ScopeImpactLikelihood
Integrity
Confidentiality

Technical Impact: Modify Application Data; Read Application Data

If a released resource is subsequently reused or reallocated, then an attempt to use the original resource might allow access to sensitive data that is associated with a different user or entity.
Other
Availability

Technical Impact: Other; DoS: Crash, Exit, or Restart

When a resource is released it might not be in an expected state, later attempts to access the resource may lead to resultant errors that may lead to a crash.
+ Demonstrative Examples

Example 1

The following code shows a simple example of a use after free error:

(bad)
Example Language:
char* ptr = (char*)malloc (SIZE);
if (err) {
abrt = 1;
free(ptr);

}
...
if (abrt) {
logError("operation aborted before commit", ptr);

}

When an error occurs, the pointer is immediately freed. However, this pointer is later incorrectly used in the logError function.

Example 2

The following code shows a simple example of a double free error:

(bad)
Example Language:
char* ptr = (char*)malloc (SIZE);
...
if (abrt) {
free(ptr);

}
...
free(ptr);

Double free vulnerabilities have two common (and sometimes overlapping) causes:

  • Error conditions and other exceptional circumstances
  • Confusion over which part of the program is responsible for freeing the memory

Although some double free vulnerabilities are not much more complicated than the previous example, most are spread out across hundreds of lines of code or even different files. Programmers seem particularly susceptible to freeing global variables more than once.

Example 3

In the following C/C++ example the method processMessage is used to process a message received in the input array of char arrays. The input message array contains two char arrays: the first is the length of the message and the second is the body of the message. The length of the message is retrieved and used to allocate enough memory for a local char array, messageBody, to be created for the message body. The messageBody is processed in the method processMessageBody that will return an error if an error occurs while processing. If an error occurs then the return result variable is set to indicate an error and the messageBody char array memory is released using the method free and an error message is sent to the logError method.

(bad)
Example Language:
#define FAIL 0
#define SUCCESS 1
#define ERROR -1
#define MAX_MESSAGE_SIZE 32

int processMessage(char **message)
{
int result = SUCCESS;

int length = getMessageLength(message[0]);
char *messageBody;

if ((length > 0) && (length < MAX_MESSAGE_SIZE)) {
messageBody = (char*)malloc(length*sizeof(char));
messageBody = &message[1][0];

int success = processMessageBody(messageBody);

if (success == ERROR) {
result = ERROR;
free(messageBody);

}

}
else {
printf("Unable to process message; invalid message length");
result = FAIL;

}

if (result == ERROR) {
logError("Error processing message", messageBody);

}

return result;

}

However, the call to the method logError includes the messageBody after the memory for messageBody has been released using the free method. This can cause unexpected results and may lead to system crashes. A variable should never be used after its memory resources have been released.

(good)
Example Language:
...
messageBody = (char*)malloc(length*sizeof(char));
messageBody = &message[1][0];

int success = processMessageBody(messageBody);

if (success == ERROR) {
result = ERROR;
logError("Error processing message", messageBody);
free(messageBody);

}
...
+ Observed Examples
ReferenceDescription
chain: race condition might allow resource to be released before operating on it, leading to NULL dereference
+ Memberships
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.
NatureTypeIDName
MemberOfCategoryCategory8082010 Top 25 - Weaknesses On the Cusp
MemberOfViewView884CWE Cross-section
MemberOfCategoryCategory983SFP Secondary Cluster: Faulty Resource Use
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
Software Fault PatternsSFP15Faulty Resource Use
CERT C Secure CodingFIO46-CCWE More AbstractDo not access a closed file
CERT C Secure CodingMEM30-CCWE More AbstractDo not access freed memory
+ Content History
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships
2010-02-16CWE Content TeamMITRE
updated Demonstrative_Examples, Description, Name, Relationships
2010-09-27CWE Content TeamMITRE
updated Observed_Examples, Relationships
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Demonstrative_Examples, Relationships
2013-02-21CWE Content TeamMITRE
updated Relationships
2014-02-18CWE Content TeamMITRE
updated Applicable_Platforms
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Demonstrative_Examples, Taxonomy_Mappings
Previous Entry Names
Change DatePrevious Entry Name
2010-02-16Use of a Resource after Expiration or Release

More information is available — Please select a different filter.
Page Last Updated: November 14, 2017