Avoid excessive stack allocations, particularly in situations where the growth of the stack can be controlled or influenced by an attacker. See INT04-C. Enforce limits on integer values originating from tainted sources for more information on preventing attacker-controlled integers from exhausting memory.

Noncompliant Code Example

The C Standard includes support for variable length arrays (VLAs). If the array length is derived from an untrusted data source, an attacker can cause the process to perform an excessive allocation on the stack.

This noncompliant code example temporarily stores data read from a source file into a buffer. The buffer is allocated on the stack as a VLA of size bufsize. If bufsize can be controlled by a malicious user, this code can be exploited to cause a denial-of-service attack:

int copy_file(FILE *src, FILE *dst, size_t bufsize) {
  char buf[bufsize];

  while (fgets(buf, bufsize, src)) {
    if (fputs(buf, dst) == EOF) {
      /* Handle error */
    }
  }

  return 0;
}

The BSD extension function alloca() behaves in a similar fashion to VLAs; its use is not recommended [Loosemore 2007].

Compliant Solution

This compliant solution replaces the VLA with a call to malloc(). If malloc() fails, the return value can be checked to prevent the program from terminating abnormally.

int copy_file(FILE *src, FILE *dst, size_t bufsize) {
  if (bufsize == 0) {
    /* Handle error */
  }
  char *buf = (char *)malloc(bufsize);
  if (!buf) {
    /* Handle error */
  }

  while (fgets(buf, bufsize, src)) {
    if (fputs(buf, dst) == EOF) {
      /* Handle error */
    }
  }
  /* ... */
  free(buf);
  return 0;
}

Noncompliant Code Example

Recursion can also lead to large stack allocations. Recursive functions must ensure that they do not exhaust the stack as a result of excessive recursions.

This noncompliant implementation of the Fibonacci function uses recursion:

unsigned long

The stack is frequently used for convenient temporary storage, because allocated memory is automatically freed when the function returns. Also, the kernel automatically grows the stack if the process accesses memory beyond the current allocation. This can fail due to lack of memory or collision with other allocated areas of the address space. However, most methods of stack allocation have no way to report failure. Instead of returning an error code, a failure to grow the stack results in the process being killed. If user input is able to influence the amount of stack memory allocated then an attacker could use this in a denial-of-service attack.

Dynamic Arrays

C99 includes support for variable length arrays. If the value used for the length of the array is influenced by user input, an attacker could cause the program to use a large number of stack pages, possibly resulting in the process being killed due to lack of memory, or simply cause the stack pointer to point to a different region of memory. The latter could result in a page fault and the process being killed or a write to an arbitrary memory location. An easy solution is to use the malloc family of functions to allocate and free memory, and handle any errors that malloc returns.

Non-Compliant Code Example

...

Compliant Solution

...

Recursion

Excessive recursion also requires the kernel to grow the stack, and can thus lead to the process being killed due to lack of memory. Depending on the algorithm, this can be much more difficult to fix than the use of dynamic arrays. However, the use of recursion in most C programs is limited in part because non-recursive solutions are often faster.

Non-Compliant Code Example

int fib1(unsigned int n)
 {
  if (n == 0) {
    return 0;
  }
  else if (n == 1 || n == 2) {
    return 1;
  }
  else {
    return fib1(n-1) + fib1(n-2);
  }
}

The amount of stack space needed grows linearly with respect to the parameter n. Large values of n have been shown to cause abnormal program termination.

Compliant Solution

This implementation of the Fibonacci functions eliminates the use of recursion:

unsigned long
int fib2(unsigned int n)
 {
  if (n == 0) {
    return 0;
  }
  else if (n == 1 || n == 2) {
    return 1;
  }

  unsigned intlong prev = 1;
  unsigned intlong cur = 1;

  unsigned int i;

  for (i = 3; i <= n; i++)
  {
    unsigned intlong tmp = cur;
    cur = cur + prev;
    prev = tmp;
  }

  return cur;
}

Risk Assessment

Stack overflow caused by excessive stack allocations or recursion could lead to abnormal termination and denial-of-service attacks.

Because there is no recursion, the amount of stack space needed does not depend on the parameter n, greatly reducing the risk of stack overflow.

Risk Assessment

Program stacks are frequently used for convenient temporary storage because allocated memory is automatically freed when the function returns. Generally, the operating system grows the stack as needed. However, growing the stack can fail because of a lack of memory or a collision with other allocated areas of the address space (depending on the architecture). When the stack is exhausted, the operating system can terminate the program abnormally. This behavior can be exploited, and an attacker can cause a denial-of-service attack if he or she can control or influence the amount of stack memory allocated.

References

Automated Detection

Related Vulnerabilities

Stack overflow has been implicated in Toyota unintended acceleration cases, where Camry and other Toyota vehicles accelerated unexpectedly.  Michael Barr testified at the trial that a stack overflow could corrupt the critical variables of the operating system, because they were located in memory adjacent to the top of the stack [Samek 2014].

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

Bibliography

...

Image Added Image Added Image Added Wiki Markup\[[Sprundel 06|http://ilja.netric.org/files/Unusual%20bugs.pdf]\] "Stack Overflow"