CWE-667: Improper Locking

How it's found

Improper Locking describes a general pattern rather than a single fixed bug. Testers use a mix of static analysis and manual code review to find where a target's code matches this pattern, then confirm exploitability by hand.

Locking is a type of synchronization behavior that ensures that multiple independently-operating processes or threads do not interfere with each other when accessing the same resource. All processes/threads are expected to follow the same steps for locking. If these steps are not followed precisely - or if no locking is done at all - then another process/thread could modify the shared resource in a way that is not visible or predictable to the original process. This can lead to data or memory corruption, denial of service, etc.

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

• DoS: Resource Consumption (CPU): Inconsistent locking discipline can lead to deadlock.

Mitigations

• Implementation: Use industry standard APIs to implement locking mechanism.

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-662: Improper Synchronization