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

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.

+ 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 Base667Insufficient Locking
Research Concepts (primary)1000
ChildOfCategoryCategory730OWASP Top Ten 2004 Category A9 - Denial of Service
Weaknesses in OWASP Top Ten (2004) (primary)711
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
+ Related Attack Patterns
CAPEC-IDAttack Pattern Name
(CAPEC Version: 1.4)
25Forced Deadlock
+ 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
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11Unrestricted Critical Resource Lock
2009-07-27Unrestricted Lock on Critical Resource
Back to top