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

Description

The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.

[object Object]

Common consequences

• Availability→DoS: Resource Consumption (CPU),DoS: Resource Consumption (Memory),DoS: Resource Consumption (Other)
  When a race condition makes it possible to bypass a resource cleanup routine or trigger multiple initialization routines, it may lead to resource exhaustion.
• Availability→DoS: Crash, Exit, or Restart,DoS: Instability
  When a race condition allows multiple control flows to access a resource simultaneously, it might lead the product(s) into unexpected states, possibly resulting in a crash.
• Confidentiality,Integrity→Read Files or Directories,Read Application Data
  When a race condition is combined with predictable resource names and loose permissions, it may be possible for an attacker to overwrite or access confidential data (CWE-59).
• Access Control→Execute Unauthorized Code or Commands,Gain Privileges or Assume Identity,Bypass Protection Mechanism
  This can have security implications when the expected synchronization is in security-critical code, such as recording whether a user is authenticated or modifying important state information that should not be influenced by an outsider.

Potential mitigations

• Architecture and Design
  In languages that support it, use synchronization primitives. Only wrap these around critical code to minimize the impact on performance.
• Architecture and Design
  Use thread-safe capabilities such as the data access abstraction in Spring.
• Architecture and Design
  [object Object]
• Implementation
  When using multithreading and operating on shared variables, only use thread-safe functions.
• Implementation
  Use atomic operations on shared variables. Be wary of innocent-looking constructs such as "x++". This may appear atomic at the code layer, but it is actually non-atomic at the instruction layer, since it involves a read, followed by a computation, followed by a write.
• Implementation
  Use a mutex if available, but be sure to avoid related weaknesses such as CWE-412.
• Implementation
  Avoid double-checked locking (CWE-609) and other implementation errors that arise when trying to avoid the overhead of synchronization.
• Implementation
  Disable interrupts or signals over critical parts of the code, but also make sure that the code does not go into a large or infinite loop.
• Implementation
  Use the volatile type modifier for critical variables to avoid unexpected compiler optimization or reordering. This does not necessarily solve the synchronization problem, but it can help.
• Architecture and Design,Operation
  Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database ad

Related CWEs

Recent CVEs classified under this CWE