[Bug stdio/16617] New: printf stack overflow with many format specs (CVE-2012-3406)

["jsm28 at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=16617

            Bug ID: 16617
           Summary: printf stack overflow with many format specs
                    (CVE-2012-3406)
           Product: glibc
           Version: 2.19
            Status: NEW
          Severity: normal
          Priority: P2
         Component: stdio
          Assignee: unassigned at sourceware dot org
          Reporter: jsm28 at gcc dot gnu.org

printf has an alloca that can overflow the stack when there are many format
specifiers in a format string, as illustrated by the following testcase:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/resource.h>

#define LIMIT 1000000

int
main (void)
{
  struct rlimit lim;
  getrlimit (RLIMIT_STACK, &lim);
  lim.rlim_cur = 1048576;
  setrlimit (RLIMIT_STACK, &lim);
  char *fmtstr = malloc (4 * LIMIT + 1);
  if (fmtstr == NULL)
    abort ();
  char *output = malloc (LIMIT + 1);
  if (output == NULL)
    abort ();
  for (size_t i = 0; i < LIMIT; i++)
    memcpy (fmtstr + 4 * i, "%1$d", 4);
  fmtstr[4 * LIMIT] = '\0';
  int ret = snprintf (output, LIMIT + 1, fmtstr, 0);
  if (ret != LIMIT)
    abort ();
  for (size_t i = 0; i < LIMIT; i++)
    if (output[i] != '0')
      abort ();
  return 0;
}

Notes:

* This is apparently CVE-2012-3406.  I'm not asserting here whether it is or is
not a security issue, but on general principles all glibc functions should
bound their stack usage to avoid stack overflows with large but valid
arguments, since stack overflows don't result in useful error reporting.

* https://bugzilla.redhat.com/show_bug.cgi?id=826943 has a patch (which I have
not tested), although it includes an excessively large testcase when something
like the above generating the format string at runtime would seem better.

* https://sourceware.org/ml/libc-alpha/2012-02/msg00092.html has an assertion
that the alloca is OK (which I disagree with on the first principle above
regarding avoiding stack overflow, whether or not it is exploitable).  The
followup https://sourceware.org/ml/libc-alpha/2012-02/msg00102.html discusses
other possible overflows there, though the stack would overflow first so they
don't need considering until the use of the stack for large allocations is
resolved.

-- 
You are receiving this mail because:
You are on the CC list for the bug.