Improper Synchronization

Draft Class

Structure: Simple

Description

The product utilizes multiple threads or processes to allow temporary access to a shared resource that can only be exclusive to one process at a time, but it does not properly synchronize these actions, which might cause simultaneous accesses of this resource by multiple threads or processes.

Extended Description

Synchronization refers to a variety of behaviors and mechanisms that allow two or more independently-operating processes or threads to ensure that they operate on shared resources in predictable ways that do not interfere with each other. Some shared resource operations cannot be executed atomically; that is, multiple steps must be guaranteed to execute sequentially, without any interference by other processes. Synchronization mechanisms vary widely, but they may include locking, mutexes, and semaphores. When a multi-step operation on a shared resource cannot be guaranteed to execute independent of interference, then the resulting behavior can be unpredictable. Improper synchronization could lead to data or memory corruption, denial of service, etc.

Common Consequences 1

Scope: IntegrityConfidentialityOther

Impact: Modify Application DataRead Application DataAlter Execution Logic

Potential Mitigations 1

Phase: Implementation

Use industry standard APIs to synchronize your code.

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 /

ID : DX-170

The following code intends to fork a process, then have both the parent and child processes print a single line.

Code Example:

Bad

/* Make timing window a little larger... /

One might expect the code to print out something like:

``` PARENT child ```

However, because the parent and child are executing concurrently, and stdout is flushed each time a character is printed, the output might be mixed together, such as:

``` PcAhRiElNdT [blank line] [blank line] ```

Observed Examples 2

CVE-2021-1782Chain: improper locking (Improper Locking) leads to race condition (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')), as exploited in the wild per CISA KEV.

CVE-2009-0935Attacker provides invalid address to a memory-reading function, causing a mutex to be unlocked twice

Modes of Introduction

Architecture and Design

Implementation

Related Attack Patterns

Related Weaknesses

ChildOf:

Improper Control of a Resource Through its Lifetime (CWE-664)

ChildOf:

Insufficient Control Flow Management (CWE-691)

CanPrecede:

Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') (CWE-362)

Taxonomy Mapping

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

Notes

MaintenanceDeeper research is necessary for synchronization and related mechanisms, including locks, mutexes, semaphores, and other mechanisms. Multiple entries are dependent on this research, which includes relationships to concurrency, race conditions, reentrant functions, etc. Improper Synchronization and its children - including Improper Locking, Missing Synchronization, Incorrect Synchronization, and others - may need to be modified significantly, along with their relationships.