CWE-834: Excessive Iteration
Official CWE-834 CWE context with Glexia analysis, remediation guidance, related CVEs, and ATT&CK context.
Glexia's Take
CWE-834: Excessive Iteration
Excessive Iteration represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Executive Impact
- Availability: DoS: Resource Consumption (CPU),DoS: Resource Consumption (Memory),DoS: Amplification,DoS: Crash, Exit, or Restart: Excessive looping will cause unexpected consumption of resources, such as CPU cycles or memory. The product's operation may slow down, or cause a long time to respond. If limited resources such as memory are consumed for each iteration, the loop may eventually cause a crash or program exit due to exhaustion of resources, such as an out-of-memory error.
Developer Pattern
CWE-834 is the kind of defect developers can usually prevent with explicit validation, safer framework defaults, and tests that exercise hostile input or unsafe state transitions.
Confidence
high confidence from CWE-834, 4.20.
Official CWE Definition
CWE-834: Excessive Iteration
The product performs an iteration or loop without sufficiently limiting the number of times that the loop is executed.
If the iteration can be influenced by an attacker, this weakness could allow attackers to consume excessive resources such as CPU or memory. In many cases, a loop does not need to be infinite in order to cause enough resource consumption to adversely affect the product or its host system; it depends on the amount of resources consumed per iteration.
Developer And Remediation Guidance
How teams prevent and detect this weakness
Causes
- In this example a mistake exists in the code where the exit condition contained in flg is never called. This results in the function calling itself over and over again until the stack is exhausted. Note that the only difference between the Good and Bad examples is that the recursion flag will change value and cause the recursive call to return.
- For this example, the method isReorderNeeded is part of a bookstore application that determines if a particular book needs to be reordered based on the current inventory count and the rate at which the book is being sold. However, the while loop will become an infinite loop if the rateSold input parameter has a value of zero since the inventoryCount will never fall below the minimumCount. In this case the input parameter should be validated to ensure that a value of zero does not cause an infinite loop, as in the following code.
Remediation
- Use safe APIs
- Centralize the control
- Add regression tests
- Review logs and telemetry for attempted abuse
Detection
- Dynamic Analysis with Manual Results Interpretation: [object Object]
- Manual Static Analysis - Source Code: [object Object]
- Automated Static Analysis - Source Code: [object Object]
- Architecture or Design Review: [object Object]
Mappings
Related CVEs, CWEs, and ATT&CK context
Related CWEs
- CWE-1322: Use of Blocking Code in Single-threaded, Non-blocking Context
- CWE-1339: Insufficient Precision or Accuracy of a Real Number
- CWE-606: Unchecked Input for Loop Condition
- CWE-674: Uncontrolled Recursion
- CWE-691: Insufficient Control Flow Management
- CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')
- CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')
ATT&CK Relevance
ATT&CK relevance is shown only when reviewed or responsibly inferred.