logo

Memory Allocation with Excessive Size Value

Draft Variant
Structure: Simple
Description

The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.

Common Consequences 1
Scope: Availability

Impact: DoS: Resource Consumption (Memory)

Not controlling memory allocation can result in a request for too much system memory, possibly leading to a crash of the application due to out-of-memory conditions, or the consumption of a large amount of memory on the system.
Detection Methods 2
FuzzingHigh
Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.
Automated Static AnalysisHigh
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Potential Mitigations 2
Phase: ImplementationArchitecture and Design
Perform adequate input validation against any value that influences the amount of memory that is allocated. Define an appropriate strategy for handling requests that exceed the limit, and consider supporting a configuration option so that the administrator can extend the amount of memory to be used if necessary.
Phase: Operation
Run your program using system-provided resource limits for memory. This might still cause the program to crash or exit, but the impact to the rest of the system will be minimized.
Demonstrative Examples 6
Consider the following code, which accepts an untrusted size value and allocates a buffer to contain a string of the given size.

Code Example:

Bad
C
c

/* ignore integer overflow (CWE-190) for this example /

c
Suppose an attacker provides a size value of:
``` 12345678 ```
This will cause 305,419,896 bytes (over 291 megabytes) to be allocated for the string.
Consider the following code, which accepts an untrusted size value and uses the size as an initial capacity for a HashMap.

Code Example:

Bad
Java
java
The HashMap constructor will verify that the initial capacity is not negative, however there is no check in place to verify that sufficient memory is present. If the attacker provides a large enough value, the application will run into an OutOfMemoryError.

ID : DX-137

This code performs a stack allocation based on a length calculation.

Code Example:

Bad
C
c
Since a and b are declared as signed ints, the "a - b" subtraction gives a negative result (-1). However, since len is declared to be unsigned, len is cast to an extremely large positive number (on 32-bit systems - 4294967295). As a result, the buffer buf[len] declaration uses an extremely large size to allocate on the stack, very likely more than the entire computer's memory space.
Miscalculations usually will not be so obvious. The calculation will either be complicated or the result of an attacker's input to attain the negative value.

ID : DX-138

This example shows a typical attempt to parse a string with an error resulting from a difference in assumptions between the caller to a function and the function's action.

Code Example:

Bad
C

int proc_msg(char *s, int msg_len) {



// Note space at the end of the string - assume all strings have preamble with space*
int pre_len = sizeof("preamble: ");
char buf[pre_len - msg_len];


c


char *s = "preamble: message\n";
char *sl = strchr(s, ':'); // Number of characters up to ':' (not including space)
int jnklen = sl == NULL ? 0 : sl - s; // If undefined pointer, use zero length
int ret_val = proc_msg ("s", jnklen); // Violate assumption of preamble length, end up with negative value, blow out stack
The buffer length ends up being -1, resulting in a blown out stack. The space character after the colon is included in the function calculation, but not in the caller's calculation. This, unfortunately, is not usually so obvious but exists in an obtuse series of calculations.
The following code obtains an untrusted number that is used as an index into an array of messages.
Code Example:
Bad
Perl
perl
The index is not validated at all (Improper Validation of Array Index), so it might be possible for an attacker to modify an element in @messages that was not intended. If an index is used that is larger than the current size of the array, the Perl interpreter automatically expands the array so that the large index works.
If $num is a large value such as 2147483648 (1<<31), then the assignment to $messages[$num] would attempt to create a very large array, then eventually produce an error message such as:
Out of memory during array extend
This memory exhaustion will cause the Perl program to exit, possibly a denial of service. In addition, the lack of memory could also prevent many other programs from successfully running on the system.
This example shows a typical attempt to parse a string with an error resulting from a difference in assumptions between the caller to a function and the function's action. The buffer length ends up being -1 resulting in a blown out stack. The space character after the colon is included in the function calculation, but not in the caller's calculation. This, unfortunately, is not usually so obvious but exists in an obtuse series of calculations.
Code Example:
Bad
C
int proc_msg(char *s, int msg_len)
{


c
Code Example:
Good
C
int proc_msg(char *s, int msg_len)
{


c
  
Observed Examples 6
CVE-2019-19911Chain: Python library does not limit the resources used to process images that specify a very large number of bands (Improper Validation of Specified Quantity in Input), leading to excessive memory consumption (Memory Allocation with Excessive Size Value) or an integer overflow (Integer Overflow or Wraparound).
CVE-2010-3701program uses ::alloca() for encoding messages, but large messages trigger segfault
CVE-2008-1708memory consumption and daemon exit by specifying a large value in a length field
CVE-2008-0977large value in a length field leads to memory consumption and crash when no more memory is available
CVE-2006-3791large key size in game program triggers crash when a resizing function cannot allocate enough memory
CVE-2004-2589large Content-Length HTTP header value triggers application crash in instant messaging application due to failure in memory allocation
  
References 2
The Art of Software Security Assessment
Mark Dowd, John McDonald, and Justin Schuh
Addison Wesley
2006
ID: REF-62
Automated Source Code Security Measure (ASCSM)
Object Management Group (OMG)
01-2016
http://www.omg.org/spec/ASCSM/1.0/
ID: REF-962
 
  
    
 
 
Applicable Platforms 
 
 
 
 
 
Languages:
 
 
 C : UndeterminedC++ : UndeterminedNot Language-Specific : Undetermined 
  
  
 
 
 
  
 
 
Modes of Introduction 
 
 
 
 
 
  Implementation  
 
 
 
    
Alternate Terms 
Stack Exhaustion
When a weakness allocates excessive memory on the stack, it is often described as "stack exhaustion," which is a technical impact of the weakness. This technical impact is often encountered as a consequence of Memory Allocation with Excessive Size Value and/or Improperly Controlled Sequential Memory Allocation.
  
 
 
Functional Areas 
 
 
 
     
  1. Memory Management
    2.  
 
 
  
 
 
Affected Resources 
 
 
 
     
  1. Memory
    2.  
 
 
  
 
 
Related Weaknesses 
 
 
 
 
  ChildOf:
 Allocation of Resources Without Limits or Throttling (CWE-770) 
  CanPrecede:
 NULL Pointer Dereference (CWE-476) 
 
 
 
 
Taxonomy Mapping 
  • WASC
  • CERT C Secure Coding
  • SEI CERT Perl Coding Standard
  • OMG ASCSM
  
Notes 
RelationshipThis weakness can be closely associated with integer overflows (Integer Overflow or Wraparound). Integer overflow attacks would concentrate on providing an extremely large number that triggers an overflow that causes less memory to be allocated than expected. By providing a large value that does not trigger an integer overflow, the attacker could still cause excessive amounts of memory to be allocated.
Applicable Platform

Uncontrolled memory allocation is possible in many languages, such as dynamic array allocation in perl or initial size parameters in Collections in Java. However, languages like C and C++ where programmers have the power to more directly control memory management will be more susceptible.