CWE-400 Detail

The product does not properly control the allocation and maintenance of a limited resource.

Modes Of Introduction

Operation : The product could be operated in a system or environment with lower resource limits than expected, which might make it easier for attackers to consume all available resources.
System Configuration : The product could be configured with lower resource limits than expected, which might make it easier for attackers to consume all available resources.
Architecture and Design : The designer might not consider how to handle and throttle excessive resource requests, which typically requires careful planning to handle more gracefully than a crash or exit.
Implementation

Applicable Platforms

Language

Class: Not Language-Specific (Undetermined)

Technologies

Class: Not Technology-Specific (Undetermined)

Common Consequences

Observed Examples

Potential Mitigations

Phases : Architecture and Design
Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
Phases : Architecture and Design
Phases : Architecture and Design
Ensure that protocols have specific limits of scale placed on them.
Phases : Implementation
Ensure that all failures in resource allocation place the system into a safe posture.

Detection Methods

Automated Static Analysis

Effectiveness : Limited

Automated Dynamic Analysis

Certain automated dynamic analysis techniques may be effective in spotting resource exhaustion problems, especially with resources such as processes, memory, and connections. The technique may involve generating a large number of requests to the product within a short time frame.
Effectiveness : Moderate

Fuzzing

While fuzzing is typically geared toward finding low-level implementation bugs, it can inadvertently find resource exhaustion problems. This can occur when the fuzzer generates a large number of test cases but does not restart the targeted product in between test cases. If an individual test case produces a crash, but it does not do so reliably, then an inability to handle resource exhaustion may be the cause.
Effectiveness : Opportunistic

Vulnerability Mapping Notes

Justification : CWE-400 is intended for incorrect behaviors in which the product is expected to track and restrict how many resources it consumes, but CWE-400 is often misused because it is conflated with the "technical impact" of vulnerabilities in which resource consumption occurs. It is sometimes used for low-information vulnerability reports. It is a level-1 Class (i.e., a child of a Pillar).
Comment : Closely analyze the specific mistake that is causing resource consumption, and perform a CWE mapping for that mistake. Consider children/descendants such as CWE-770: Allocation of Resources Without Limits or Throttling, CWE-771: Missing Reference to Active Allocated Resource, CWE-410: Insufficient Resource Pool, CWE-772: Missing Release of Resource after Effective Lifetime, CWE-834: Excessive Iteration, CWE-405: Asymmetric Resource Consumption (Amplification), and others.

Related Attack Patterns

Notes

"Resource consumption" could be interpreted as a consequence instead of an insecure behavior, so this entry is being considered for modification. It appears to be referenced too frequently when more precise mappings are available. Some of its children, such as CWE-771, might be better considered as a chain.
Vulnerability theory is largely about how behaviors and resources interact. "Resource exhaustion" can be regarded as either a consequence or an attack, depending on the perspective. This entry is an attempt to reflect the underlying weaknesses that enable these attacks (or consequences) to take place.

References

REF-18

The CLASP Application Security Process
Secure Software, Inc..
https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf

REF-386

Detection and Prediction of Resource-Exhaustion Vulnerabilities
Joao Antunes, Nuno Ferreira Neves, Paulo Verissimo.
https://www.di.fc.ul.pt/~nuno/PAPERS/ISSRE08.pdf

REF-387

Resource exhaustion
D.J. Bernstein.
http://cr.yp.to/docs/resources.html

REF-388

Resource exhaustion
Pascal Meunier.
http://homes.cerias.purdue.edu/~pmeunier/secprog/sanitized/class1/6.resource%20exhaustion.ppt

REF-7

Writing Secure Code
Michael Howard, David LeBlanc.
https://www.microsoftpressstore.com/store/writing-secure-code-9780735617223

Submission

Modifications