1004
Scope Impact Likelihood
Integrity
Availability
Modify Application Data
DoS: Instability
DoS: Crash, Exit, or Restart
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.)
Effectiveness = High
Potential Mitigations
Phase: Architecture and Design
Use a non-conflicting privilege scheme.
Phase: Architecture and Design
Phase: Implementation
Use synchronization when locking a resource.
Demonstrative Examples
Example 1:
The following function attempts to acquire a lock in order to perform operations on a shared
resource.
Example Language: C (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.
Example Language: C (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);
}
Example 2:
This Java example shows a simple BankAccount class with deposit and withdraw methods.
CWE Version 4.14
CWE-413: Improper Resource Locking
CWE-413: Improper Resource Locking