Home > CAPEC List > CAPEC-25: Forced Deadlock (Version 2.10)  

CAPEC-25: Forced Deadlock

Forced Deadlock
Definition in a New Window Definition in a New Window
Attack Pattern ID: 25
Abstraction: Meta
Status: Stable
Completeness: Complete
Presentation Filter:
+ Summary

The adversary triggers and exploits a deadlock condition in the target software to cause a denial of service. A deadlock can occur when two or more competing actions are waiting for each other to finish, and thus neither ever does. Deadlock conditions can be difficult to detect.

+ Attack Execution Flow
  1. The adversary initiates an exploratory phase to get familiar with the system.

  2. The adversary triggers a first action (such as holding a resource) and initiates a second action which will wait for the first one to finish.

  3. If the target program has a deadlock condition, the program waits indefinitely resulting in a denial of service.

+ Attack Prerequisites
  • The target host has a deadlock condition. There are four conditions for a deadlock to occur, known as the Coffman conditions. [R.25.3][REF-6]

  • The target host exposes an API to the user.

+ Typical Severity


+ Typical Likelihood of Exploit

Likelihood: Low

+ Methods of Attack
  • Analysis
  • API Abuse
+ Examples-Instances


An example of a deadlock which may occur in database products is the following. Client applications using the database may require exclusive access to a table, and in order to gain exclusive access they ask for a lock. If one client application holds a lock on a table and attempts to obtain the lock on a second table that is already held by a second client application, this may lead to deadlock if the second application then attempts to obtain the lock that is held by the first application (Source: Wikipedia, http://en.wikipedia.org/wiki/Deadlock)

+ Attacker Skills or Knowledge Required

Skill or Knowledge Level: Medium

This type of attack may be sophisticated and require knowledge about the system's resources and APIs.

+ Probing Techniques

The adversary can probe by trying to hold resources and call APIs which are directly using the same resources.

The adversary may try to find actions (threads, processes) competing for the same resources.

+ Solutions and Mitigations

Use known algorithm to avoid deadlock condition (for instance non-blocking synchronization algorithms).

For competing actions, use well-known libraries which implement synchronization.

+ Attack Motivation-Consequences
ScopeTechnical ImpactNote
DoS: resource consumption (other)
A successful forced deadlock attack compromises the availability of the system by exhausting its available resources.
+ Purposes
  • Exploitation
+ CIA Impact
Confidentiality Impact: LowIntegrity Impact: LowAvailability Impact: High
+ Technical Context
Architectural Paradigms
+ References
[R.25.1] [REF-2] G. Hoglund and G. McGraw. "Exploiting Software: How to Break Code". Addison-Wesley. February 2004.
[R.25.2] [REF-3] "Common Weakness Enumeration (CWE)". CWE-412 - Unrestricted Critical Resource Lock. Draft. The MITRE Corporation. 2007. <http://cwe.mitre.org/data/definitions/412.html>.
[R.25.3] [REF-6] "Wikipedia". Deadlock. The Wikimedia Foundation, Inc. <http://en.wikipedia.org/wiki/Deadlock>.
+ Content History
CAPEC Content TeamThe MITRE Corporation2014-06-23Internal_CAPEC_Team
CAPEC Content TeamThe MITRE Corporation2017-01-09Updated Related_Attack_Patterns, Type (Relationship -> Attack_Pattern)Internal
CAPEC Content TeamThe MITRE Corporation2017-05-01Updated Activation_Zone, Attack_Motivation-Consequences, Attack_Phases, Description Summary, Injection_Vector, Payload, Payload_Activation_Impact, Probing_Techniques, Related_Weaknesses, Solutions_and_MitigationsInternal
More information is available — Please select a different filter.
Page Last Updated or Reviewed: May 01, 2017