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.1)  
ID

CWE-413: Improper Resource Locking

Weakness ID: 413
Abstraction: Base
Structure: Simple
Status: Draft
Presentation Filter:
+ Description
The software does not lock or does not correctly lock a resource when the software must have exclusive access to the resource.
+ Extended Description
When a resource is not properly locked, an attacker could modify the resource while it is being operated on by the software. This might violate the software's assumption that the resource will not change, potentially leading to unexpected behaviors.
+ 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 "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfBaseBase - a weakness that is described in an abstract fashion, but with sufficient details to infer specific methods for detection and prevention. More general than a Variant weakness, but more specific than a Class weakness.667Improper Locking
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.591Sensitive Data Storage in Improperly Locked Memory
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.411Resource Locking Problems
ParentOfVariantVariant - a weakness that is described at a very low level of detail, typically limited to a specific language or technology. More specific than a Base weakness.591Sensitive Data Storage in Improperly Locked Memory
+ 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
+ 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

Class: Language-Independent (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
Availability

Technical Impact: Modify Application Data; DoS: Instability; DoS: Crash, Exit, or Restart

+ Demonstrative Examples

Example 1

The following function attempts to acquire a lock in order to perform operations on a shared resource.

(bad code)
Example Language:
void f(pthread_mutex_t *mutex) {
pthread_mutex_lock(mutex);

/* access shared resource */


pthread_mutex_unlock(mutex);
}

However, the code does not check the value returned by pthread_mutex_lock() for errors. If pthread_mutex_lock() cannot acquire the mutex for any reason the function may introduce a race condition into the program and result in undefined behavior.

In order to avoid data races correctly written programs must check the result of thread synchronization functions and appropriately handle all errors, either by attempting to recover from them or reporting it to higher levels.

(good code)
Example Language:
int f(pthread_mutex_t *mutex) {
int result;

result = pthread_mutex_lock(mutex);
if (0 != result)
return result;


/* access shared resource */


return pthread_mutex_unlock(mutex);
}

Example 2

This Java example shows a simple BankAccount class with deposit and withdraw methods.

(bad code)
Example Language: Java 
public class BankAccount {

// variable for bank account balance
private double accountBalance;

// constructor for BankAccount
public BankAccount() {
accountBalance = 0;
}

// method to deposit amount into BankAccount
public void deposit(double depositAmount) {

double newBalance = accountBalance + depositAmount;
accountBalance = newBalance;
}

// method to withdraw amount from BankAccount
public void withdraw(double withdrawAmount) {

double newBalance = accountBalance - withdrawAmount;
accountBalance = newBalance;
}

// other methods for accessing the BankAccount object
...
}

However, the deposit and withdraw methods have shared access to the account balance private class variable. This can result in a race condition if multiple threads attempt to call the deposit and withdraw methods simultaneously where the account balance is modified by one thread before another thread has completed modifying the account balance. For example, if a thread attempts to withdraw funds using the withdraw method before another thread that is depositing funds using the deposit method completes the deposit then there may not be sufficient funds for the withdraw transaction.

To prevent multiple threads from having simultaneous access to the account balance variable the deposit and withdraw methods should be synchronized using the synchronized modifier.

(good code)
Example Language: Java 
public class BankAccount {
...
// synchronized method to deposit amount into BankAccount
public synchronized void deposit(double depositAmount) {
...
}

// synchronized method to withdraw amount from BankAccount
public synchronized void withdraw(double withdrawAmount) {
...
}

...
}

An alternative solution is to use a lock object to ensure exclusive access to the bank account balance variable. As shown below, the deposit and withdraw methods use the lock object to set a lock to block access to the BankAccount object from other threads until the method has completed updating the bank account balance variable.

(good code)
Example Language: Java 
public class BankAccount {
...
// lock object for thread access to methods
private ReentrantLock balanceChangeLock;

// condition object to temporarily release lock to other threads
private Condition sufficientFundsCondition;

// method to deposit amount into BankAccount
public void deposit(double amount) {

// set lock to block access to BankAccount from other threads
balanceChangeLock.lock();
try {
double newBalance = balance + amount;
balance = newBalance;

// inform other threads that funds are available
sufficientFundsCondition.signalAll();
} catch (Exception e) {...}
finally {
// unlock lock object
balanceChangeLock.unlock();
}
}

// method to withdraw amount from bank account
public void withdraw(double amount) {

// set lock to block access to BankAccount from other threads
balanceChangeLock.lock();
try {
while (balance < amount) {

// temporarily unblock access

// until sufficient funds are available
sufficientFundsCondition.await();
}
double newBalance = balance - amount;
balance = newBalance;
} catch (Exception e) {...}
finally {
// unlock lock object
balanceChangeLock.unlock();
}
}
...
}
+ Potential Mitigations

Phase: Architecture and Design

Use a non-conflicting privilege scheme.

Phases: Architecture and Design; Implementation

Use synchronization when locking a resource.
+ 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
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.852CERT Java Secure Coding Section 07 - Visibility and Atomicity (VNA)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.853CERT Java Secure Coding Section 08 - Locking (LCK)
MemberOfCategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.986SFP Secondary Cluster: Missing Lock
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERInsufficient Resource Locking
CERT Java Secure CodingVNA00-JEnsure visibility when accessing shared primitive variables
CERT Java Secure CodingVNA02-JEnsure that compound operations on shared variables are atomic
CERT Java Secure CodingLCK00-JUse private final lock objects to synchronize classes that may interact with untrusted code
Software Fault PatternsSFP19Missing Lock
+ Content History
Submissions
Submission DateSubmitterOrganization
PLOVER
Contributions
Contribution DateContributorOrganization
2010-04-30Martin SeborCisco Systems, Inc.
Provided Demonstrative Example
Modifications
Modification DateModifierOrganization
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2010-06-21CWE Content TeamMITRE
updated Demonstrative_Examples
2010-09-27CWE Content TeamMITRE
updated Description, Name
2010-12-13CWE Content TeamMITRE
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITRE
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITRE
updated Demonstrative_Examples, Relationships
2012-10-30CWE Content TeamMITRE
updated Potential_Mitigations
2014-07-30CWE Content TeamMITRE
updated Relationships, Taxonomy_Mappings
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
Previous Entry Names
Change DatePrevious Entry Name
2010-09-27Insufficient Resource Locking

More information is available — Please select a different filter.
Page Last Updated: March 29, 2018