This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug stdio/16617] New: printf stack overflow with many format specs (CVE-2012-3406)
- From: "jsm28 at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 20 Feb 2014 23:43:21 +0000
- Subject: [Bug stdio/16617] New: printf stack overflow with many format specs (CVE-2012-3406)
- Auto-submitted: auto-generated
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.