CWE-667: Improper Locking | Glexia
CWE-667 (Improper Locking) weakness overview with consequences, detection methods, mitigations, related CVEs and MITRE ATT&CK context.
Glexia's Take · Automated analysis
CWE-667: Improper Locking
Improper Locking represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Executive Impact
- Availability: DoS: Resource Consumption (CPU): Inconsistent locking discipline can lead to deadlock.
Developer Pattern
CWE-667 is the kind of defect developers can usually prevent with explicit validation, safer framework defaults, and tests that exercise hostile input or unsafe state transitions.
Automation confidence
high confidence from CWE-667, 4.20.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Official CWE Definition
CWE-667: Improper Locking
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
Developer And Remediation Guidance
How teams prevent and detect this weakness
Causes
- In the following Java snippet, methods are defined to get and set a long field in an instance of a class that is shared across multiple threads. Because operations on double and long are nonatomic in Java, concurrent access may cause unexpected behavior. Thus, all operations on long and double fields should be synchronized.
- This code tries to obtain a lock for a file, then writes to it. PHP by default will wait indefinitely until a file lock is released. If an attacker is able to obtain the file lock, this code will pause execution, possibly leading to denial of service for other users. Note that in this case, if an attacker can perform an flock() on the file, they may already have privileges to destroy the log file. However, this still impacts the execution of other programs that depend on flock().
- The following function attempts to acquire a lock in order to perform operations on a 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.
- It may seem that the following bit of code achieves thread safety while avoiding unnecessary synchronization... The programmer wants to guarantee that only one Helper() object is ever allocated, but does not want to pay the cost of synchronization every time this code is called.,Suppose that helper is not initialized. Then, thread A sees that helper==null and enters the synchronized block and begins to execute:,If a second thread, thread B, takes over in the middle of this call and helper has not finished running the constructor, then thread B may make calls on helper while its fields hold incorrect values.
Remediation
- Implementation: Use industry standard APIs to implement locking mechanism.
Detection
- 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.)
Mappings
Related CVEs, CWEs, and ATT&CK context
Related CWEs
- CWE-1232: Improper Lock Behavior After Power State Transition
- CWE-1233: Security-Sensitive Hardware Controls with Missing Lock Bit Protection
- CWE-1234: Hardware Internal or Debug Modes Allow Override of Locks
- CWE-412: Unrestricted Externally Accessible Lock
- CWE-413: Improper Resource Locking
- CWE-414: Missing Lock Check
- CWE-609: Double-Checked Locking
- CWE-662: Improper Synchronization
- CWE-662: Improper Synchronization
- CWE-662: Improper Synchronization
- CWE-662: Improper Synchronization
- CWE-764: Multiple Locks of a Critical Resource
ATT&CK Relevance
ATT&CK relevance is shown only when reviewed or responsibly inferred.