Memory Allocation with Excessive Size Value

Draft Variant

Structure: Simple

Description

This vulnerability occurs when a program allocates memory based on a user-supplied or untrusted size value without proper validation. If an attacker provides an excessively large number, the application can attempt to allocate massive amounts of system memory, leading to a denial-of-service or system instability.

Extended Description

At its core, this flaw is about a missing safety check. When an application accepts a size parameter—like the length of a file to process or the number of records to load—directly from an untrusted source (user input, network data, a file) and passes it to a memory allocation function (like `malloc`, `calloc`, or `new`) without verifying it's reasonable, the system's memory manager tries to fulfill the request. This often results in an out-of-memory crash, exhausting system resources and making the application unavailable. To prevent this, developers must implement strict bounds checking before any allocation. Establish sensible, application-specific limits for all size values derived from external inputs. Compare the requested size against a configured maximum, and reject the request if it's too large. This validation should happen as early as possible, ideally right after the input is received, to ensure the program remains stable and responsive under all conditions.

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

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

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

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];

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

int proc_msg(char *s, int msg_len) {

Code Example:

Good

int proc_msg(char *s, int msg_len) {

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

Memory Management

Affected Resources

Memory

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.