CWE-412: Unrestricted Externally Accessible Lock

Description

The product properly checks for the existence of a lock, but the lock can be externally controlled or influenced by an actor that is outside of the intended sphere of control.

This prevents the product from acting on associated resources or performing other behaviors that are controlled by the presence of the lock. Relevant locks might include an exclusive lock or mutex, or modifying a shared resource that is treated as a lock. If the lock can be held for an indefinite period of time, then the denial of service could be permanent.

Potential Impact

Demonstrative Examples

function writeToLog($message){$logfile = fopen("logFile.log", "a");
                        //attempt to get logfile lock
                        if (flock($logfile, LOCK_EX)) {fwrite($logfile,$message);
                           // unlock logfile
                           flock($logfile, LOCK_UN);}else {print "Could not obtain lock on logFile.log, message not recorded\n";}}fclose($logFile);

Mitigations & Prevention

Detection Methods

• White Box — Automated code analysis techniques might not be able to reliably detect this weakness, since the application's behavior and general security model dictate which resource locks are critical. Interpretation of the weakness might require knowledge of the environment, e.g. if the existence of a file is

Real-World CVE Examples

Related Weaknesses

Taxonomy Mappings

• PLOVER: — Unrestricted Critical Resource Lock
• 7 Pernicious Kingdoms: — Deadlock
• OWASP Top Ten 2004: A9 — Denial of Service
• The CERT Oracle Secure Coding Standard for Java (2011): LCK00-J — Use private final lock objects to synchronize classes that may interact with untrusted code
• The CERT Oracle Secure Coding Standard for Java (2011): LCK07-J — Avoid deadlock by requesting and releasing locks in the same order
• Software Fault Patterns: SFP22 — Unrestricted lock