Improper Resource Locking

Draft Base

Structure: Simple

Description

The product does not lock or does not correctly lock a resource when the product 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 product. This might violate the product's assumption that the resource will not change, potentially leading to unexpected behaviors.

Common Consequences 1

Scope: IntegrityAvailability

Impact: Modify Application DataDoS: InstabilityDoS: Crash, Exit, or Restart

Detection Methods 1

Automated Static AnalysisHigh

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

Potential Mitigations 2

Phase: Architecture and Design

Use a non-conflicting privilege scheme.

Phase: Architecture and DesignImplementation

Use synchronization when locking a resource.

Demonstrative Examples 2

ID : DX-24

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

Code Example:

Bad

/* access shared resource /

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 them to higher levels.

Code Example:

Good

/* access shared resource /

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

Code Example:

Bad

Java

java

// variable for bank account balance* private double accountBalance;

java

java

// method to withdraw amount from BankAccount* public void withdraw(double withdrawAmount) { ``` double newBalance = accountBalance - withdrawAmount; accountBalance = newBalance; }

java

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.

Code Example:

Good

Java

java

// synchronized method to deposit amount into BankAccount* public synchronized void deposit(double depositAmount) { ``` ... }

java

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.

Code Example:

Good

Java

java

// lock object for thread access to methods* private ReentrantLock balanceChangeLock;

java

java

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

java

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

java

Observed Examples 1

CVE-2022-20141Chain: an operating system kernel has insufficent resource locking (Improper Resource Locking) leading to a use after free (Use After Free).

Applicable Platforms

Languages:

Not Language-Specific : Undetermined

Modes of Introduction

Architecture and Design

Implementation

Related Weaknesses

ChildOf:

Improper Locking (CWE-667)

Taxonomy Mapping

PLOVER
The CERT Oracle Secure Coding Standard for Java (2011)
The CERT Oracle Secure Coding Standard for Java (2011)
The CERT Oracle Secure Coding Standard for Java (2011)
Software Fault Patterns