CWEweakness

CWE-543 Use of Singleton Pattern Without Synchronization in a Multithreaded Context

Official page ↗
Abstraction
Variant
Structure
Simple
Status
Incomplete
Languages
C++, Java
CWE version
5.0

Description

The product uses the singleton pattern when creating a resource within a multithreaded environment.

Common consequences

• Other, Integrity: Varies by Context, Modify Application Data — The use of a singleton pattern may not be thread-safe.

Potential mitigations

• [Architecture and Design] Use the Thread-Specific Storage Pattern. See References. • [Implementation] Do not use member fields to store information in the Servlet. In multithreading environments, storing user data in Servlet member fields introduces a data access race condition. • [Implementation] Avoid using the double-checked locking pattern in language versions that cannot guarantee thread safety. This pattern may be used to avoid the overhead of a synchronized call, but in certain versions of Java (for example), this has been shown to be unsafe because it still introduces a race condition (CWE-209).

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

Related

Child of · CWE (2)

  • CWE-662 Improper Synchronization weakness
  • CWE-820 Missing Synchronization weakness