Allocation of File Descriptors or Handles Without Limits or Throttling

Description

This vulnerability occurs when an application creates file descriptors or handles for a user or process without enforcing any limits on the total number that can be opened.

Extended Description

When an application fails to throttle file handle allocation, a single user or process can exhaust the entire system's available file descriptors. This denial-of-service condition prevents other legitimate processes from opening files, sockets, or other resources, effectively crippling system functionality. Developers can prevent this by implementing per-user or per-process quotas, closing handles promptly after use, and monitoring for abnormal consumption patterns. This ensures system resources remain available for all critical operations and aligns with the principle of least privilege.

Common Consequences 1

Scope: Availability

Impact: DoS: Resource Consumption (Other)

When allocating resources without limits, an attacker could prevent all other processes from accessing the same type of resource.

Potential Mitigations 1

Phase: OperationArchitecture and Design

Strategy: Resource Limitation

Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems. When the current levels get close to the maximum that is defined for the application (see Allocation of Resources Without Limits or Throttling), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users. Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (Improper Check or Handling of Exceptional Conditions).

References 1

The Art of Software Security Assessment

Mark Dowd, John McDonald, and Justin Schuh

Addison Wesley

2006

ID: REF-62

Likelihood of Exploit

Low

Modes of Introduction

Architecture and Design

Implementation

Alternate Terms

File Descriptor Exhaustion

Related Weaknesses

ChildOf:

Allocation of Resources Without Limits or Throttling (CWE-770)

Taxonomy Mapping

Software Fault Patterns