CWE-413: Improper Resource Locking

How it's found

Improper Resource Locking is typically found by tracing untrusted input from where it enters the system to the point where it is used without the check or neutralization this weakness describes, combining manual code review with dynamic testing.

When a resource is not properly locked, an attacker could modify the resource while it is being operated on by the product. This might violate the product's assumption that the resource will not change, potentially leading to unexpected behaviors.

Vulnerable vs. safe

/* access shared resource */pthread_mutex_lock(mutex);pthread_mutex_unlock(mutex);void f(pthread_mutex_t *mutex) {}

return result;/* access shared resource */int result;result = pthread_mutex_lock(mutex);if (0 != result)return pthread_mutex_unlock(mutex);int f(pthread_mutex_t *mutex) {}

Consequences

• Modify Application Data, DoS: Instability, DoS: Crash, Exit, or Restart

Mitigations

• Architecture and Design: Use a non-conflicting privilege scheme.
• Architecture and Design/Implementation: Use synchronization when locking a resource.

Where this fits in a TurboPentest engagement

This weakness is not covered by the automated black-box pentest. IntegSec pentesters cover it in a manual engagement.

Frequently asked questions

Related CWEs

• Class weakness
  CWE-667: Improper Locking