Class · High

CWE-662: Improper Synchronization

The product utilizes multiple threads, processes, components, or systems to allow temporary access to a shared resource that can only be exclusive to one process at a time, but it does not properly sy...

CWE-662 · Class Level ·2 CVEs ·1 Mitigations

Description

The product utilizes multiple threads, processes, components, or systems 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.

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.

Potential Impact

Integrity, Confidentiality, Other

Modify Application Data, Read Application Data, Alter Execution Logic

Demonstrative Examples

The following function attempts to acquire a lock in order to perform operations on a shared resource.
Bad
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 them to higher levels.
Good
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);
                     }
The following code intends to fork a process, then have both the parent and child processes print a single line.
Bad
static void print (char * string) {
                        char * word;int counter;for (word = string; counter = *word++; ) {
                              putc(counter, stdout);fflush(stdout);
                                 /* Make timing window a little larger... */
                                 
                                 sleep(1);
                           }
                     }
                     int main(void) {
                        pid_t pid;
                           pid = fork();if (pid == -1) {exit(-2);}else if (pid == 0) {print("child\n");}else {print("PARENT\n");}exit(0);
                     }
One might expect the code to print out something like:
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:

Mitigations & Prevention

Implementation

Use industry standard APIs to synchronize your code.

Detection Methods

  • 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 sea

Real-World CVE Examples

CVE IDDescription
CVE-2021-1782Chain: improper locking (CWE-667) leads to race condition (CWE-362), 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

Taxonomy Mappings

  • CERT C Secure Coding: SIG00-C — Mask signals handled by noninterruptible signal handlers
  • CERT C Secure Coding: SIG31-C — Do not access shared objects in signal handlers
  • CLASP: — State synchronization error
  • The CERT Oracle Secure Coding Standard for Java (2011): VNA03-J — Do not assume that a group of calls to independently atomic methods is atomic
  • Software Fault Patterns: SFP19 — Missing Lock

Frequently Asked Questions

What is CWE-662?

CWE-662 (Improper Synchronization) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Class-level weakness. The product utilizes multiple threads, processes, components, or systems to allow temporary access to a shared resource that can only be exclusive to one process at a time, but it does not properly sy...

How can CWE-662 be exploited?

Attackers can exploit CWE-662 (Improper Synchronization) to modify application data, read application data, alter execution logic. This weakness is typically introduced during the Architecture and Design, Implementation phase of software development.

How do I prevent CWE-662?

Key mitigations include: Use industry standard APIs to synchronize your code.

What is the severity of CWE-662?

CWE-662 is classified as a Class-level weakness (High abstraction). It has been observed in 2 real-world CVEs.