CWE

Common Weakness Enumeration

A Community-Developed Dictionary of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors Common Weakness Scoring System
Common Weakness Risk Analysis Framework
Home > CWE List > CWE- Individual Dictionary Definition (2.6)  

Presentation Filter:

CWE-412: Unrestricted Externally Accessible Lock

 
Unrestricted Externally Accessible Lock
Weakness ID: 412 (Weakness Base)Status: Incomplete
+ Description

Description Summary

The software 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.

Extended Description

This prevents the software 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.

+ Time of Introduction
  • Architecture and Design
  • Implementation
+ Applicable Platforms

Languages

All

+ Common Consequences
ScopeEffect
Availability

Technical Impact: DoS: resource consumption (other)

When an attacker can control a lock, the program may wait indefinitely until the attacker releases the lock, causing a denial of service to other users of the program. This is especially problematic if there is a blocking operation on the lock.

+ 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 used as a lock, but the file is created in a world-writable directory.

+ Demonstrative Examples

Example 1

This code tries to obtain a lock for a file, then writes to it.

(Bad Code)
Example Language: PHP 
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);

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().

+ Observed Examples
ReferenceDescription
CVE-2001-0682Program can not execute when attacker obtains a mutex.
CVE-2002-1914Program can not execute when attacker obtains a lock on a critical output file.
CVE-2002-1915Program can not execute when attacker obtains a lock on a critical output file.
CVE-2002-0051Critical file can be opened with exclusive read access by user, preventing application of security policy. Possibly related to improper permissions, large-window race condition.
CVE-2000-0338Chain: predictable file names used for locking, allowing attacker to create the lock beforehand. Resultant from permissions and randomness.
CVE-2000-1198Chain: Lock files with predictable names. Resultant from randomness.
CVE-2002-1869Product does not check if it can write to a log file, allowing attackers to avoid logging by accessing the file using an exclusive lock. Overlaps unchecked error condition. This is not quite CWE-412, but close.
+ Potential Mitigations

Phases: Architecture and Design; Implementation

Use any access control that is offered by the functionality that is offering the lock.

Phases: Architecture and Design; Implementation

Use unpredictable names or identifiers for the locks. This might not always be possible or feasible.

Phase: Architecture and Design

Consider modifying your code to use non-blocking synchronization methods.

+ Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfCategoryCategory361Time and State
Development Concepts (primary)699
Seven Pernicious Kingdoms (primary)700
ChildOfCategoryCategory411Resource Locking Problems
Development Concepts699
ChildOfWeakness BaseWeakness Base667Improper Locking
Research Concepts (primary)1000
ChildOfCategoryCategory730OWASP Top Ten 2004 Category A9 - Denial of Service
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory853CERT Java Secure Coding Section 08 - Locking (LCK)
Weaknesses Addressed by the CERT Java Secure Coding Standard (primary)844
ChildOfCategoryCategory894SFP Cluster: Synchronization
Software Fault Pattern (SFP) Clusters (primary)888
CanAlsoBeWeakness BaseWeakness Base410Insufficient Resource Pool
Research Concepts1000
MemberOfViewView630Weaknesses Examined by SAMATE
Weaknesses Examined by SAMATE (primary)630
+ Relationship Notes

This overlaps Insufficient Resource Pool when the "pool" is of size 1. It can also be resultant from race conditions, although the timing window could be quite large in some cases.

+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERUnrestricted Critical Resource Lock
7 Pernicious KingdomsDeadlock
OWASP Top Ten 2004A9CWE_More_SpecificDenial of Service
CERT Java Secure CodingLCK00-JUse private final lock objects to synchronize classes that may interact with untrusted code
CERT Java Secure CodingLCK07-JAvoid deadlock by requesting and releasing locks in the same order
+ White Box Definitions

A weakness where:

1. either an end statement performs a blocking operation on an externally accessible lock or

2. a code path has

2.1. the start statement that performs a non-blocking operation on an externally accessible lock and

2.2. the end statement that is a condition which checks that the lock operation failed and that either

2.2.1. leads to the start statement or

2.2.2. leads to abnormal termination.

+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVERExternally Mined
Contributions
Contribution DateContributorOrganizationSource
2008-08-29KDM AnalyticsFeedback
suggested clarification of description and observed examples, which were vague and inconsistent.
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigitalExternal
updated Potential_Mitigations, Time_of_Introduction
2008-08-01KDM AnalyticsExternal
added/updated white box definitions
2008-08-15VeracodeExternal
Suggested OWASP Top Ten 2004 mapping
2008-09-08CWE Content TeamMITREInternal
updated Common_Consequences, Description, Detection_Factors, Relationships, Observed_Example, Relationship_Notes, Taxonomy_Mappings
2008-10-14CWE Content TeamMITREInternal
updated Description
2009-07-17
(Critical)
KDM AnalyticsExternal
Suggested a better name and the minimal relationship with resources regardless of their criticality.
2009-07-17KDM AnalyticsExternal
Added a White_Box_Definition and clarified the consequences.
2009-07-27CWE Content TeamMITREInternal
updated Common_Consequences, Description, Name, Potential_Mitigations, White_Box_Definitions
2011-03-29CWE Content TeamMITREInternal
updated Demonstrative_Examples
2011-06-01CWE Content TeamMITREInternal
updated Common_Consequences, Relationships, Taxonomy_Mappings
2012-05-11CWE Content TeamMITREInternal
updated Demonstrative_Examples, Relationships
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Unrestricted Critical Resource Lock
2009-07-27Unrestricted Lock on Critical Resource
Page Last Updated: February 18, 2014