vfprintf stack overflow [BZ #16617]
Commit Message
This fell through the cracks. I took Jeff Law's patch (which we carry
as a local patch in Fedora and downstream), compressed the bug23-3.c
test case, and added Joseph's test case from the bug as bug23-4.c.
Tested on x86_64-redhat-linux-gnu, with no regressions.
Comments
On Fri, 5 Dec 2014, Florian Weimer wrote:
> This fell through the cracks. I took Jeff Law's patch (which we carry as a
> local patch in Fedora and downstream), compressed the bug23-3.c test case, and
> added Joseph's test case from the bug as bug23-4.c.
What's your view of the other possible overflows there that Paul Eggert
mentioned in <https://sourceware.org/ml/libc-alpha/2012-02/msg00102.html>?
I think nspecs * sizeof (*specs) is always OK (that's the size of an
object that's already been allocated), but 2 * nspecs_size might not be
(if it can't overflow in practice, that's an accident to do with the
size of struct printf_spec, the particular sequence of allocation sizes
and how much memory it's actually possible to allocate on existing
systems, rather than because the code is sensible to keep as-is without a
check on that multiplication).
(If you agree there's a problem but think it should be kept separate, feel
free to file a separate bug / get a separate CVE for it.)
On Fri, Dec 05, 2014 at 05:01:32PM +0000, Joseph Myers wrote:
> On Fri, 5 Dec 2014, Florian Weimer wrote:
>
> > This fell through the cracks. I took Jeff Law's patch (which we carry as a
> > local patch in Fedora and downstream), compressed the bug23-3.c test case, and
> > added Joseph's test case from the bug as bug23-4.c.
>
> What's your view of the other possible overflows there that Paul Eggert
> mentioned in <https://sourceware.org/ml/libc-alpha/2012-02/msg00102.html>?
> I think nspecs * sizeof (*specs) is always OK (that's the size of an
> object that's already been allocated), but 2 * nspecs_size might not be
> (if it can't overflow in practice, that's an accident to do with the
> size of struct printf_spec, the particular sequence of allocation sizes
> and how much memory it's actually possible to allocate on existing
> systems, rather than because the code is sensible to keep as-is without a
> check on that multiplication).
If N is the size of an actual allocated object, 2*N should not be able
to overflow. If it can, it means you already have a situation where an
object is so large that legal pointer subtractions overflow ptrdiff_t,
which is a dangerous situation to begin with and should be fixed.
Rich
On 12/05/2014 12:26 PM, Rich Felker wrote:
> If N is the size of an actual allocated object, 2*N should not be able
> to overflow. If it can, it means you already have a situation where an
> object is so large that legal pointer subtractions overflow ptrdiff_t
No, because the array elements are of type struct printf_spec, which is
several bytes in size. So even if the number of bytes in the array
exceeds PTRDIFF_MAX by a factor of (say) eight, subtracting addresses of
array elements won't overflow.
Admittedly this is all a bit theoretical.
On Fri, 5 Dec 2014, Paul Eggert wrote:
> On 12/05/2014 12:26 PM, Rich Felker wrote:
> > If N is the size of an actual allocated object, 2*N should not be able
> > to overflow. If it can, it means you already have a situation where an
> > object is so large that legal pointer subtractions overflow ptrdiff_t
> No, because the array elements are of type struct printf_spec, which is
> several bytes in size. So even if the number of bytes in the array exceeds
> PTRDIFF_MAX by a factor of (say) eight, subtracting addresses of array
> elements won't overflow.
Such subtraction of pointers differing by more than SIZE_MAX / 2 bytes
does not actually work in GCC (it does a subtraction, which overflows,
then a division - and that approach is fine for all normal arguments).
I think malloc should in principle disallow allocations of more than
SIZE_MAX / 2 bytes, but right now it doesn't, and I suspect a change would
break compatibility for various existing applications that expect to do
> 2GB allocations on 32-bit systems.
On Fri, Dec 05, 2014 at 02:00:29PM -0800, Paul Eggert wrote:
> On 12/05/2014 12:26 PM, Rich Felker wrote:
> >If N is the size of an actual allocated object, 2*N should not be able
> >to overflow. If it can, it means you already have a situation where an
> >object is so large that legal pointer subtractions overflow ptrdiff_t
> No, because the array elements are of type struct printf_spec, which
> is several bytes in size. So even if the number of bytes in the
> array exceeds PTRDIFF_MAX by a factor of (say) eight, subtracting
> addresses of array elements won't overflow.
>
> Admittedly this is all a bit theoretical.
However the code allocating this object (malloc) didn't know it was
going to be used for an array of printf_spec structs. It could have
been used for an array of char, in which case the dangerous overflow
would be possible.
Rich
On Fri, Dec 05, 2014 at 10:42:30PM +0000, Joseph Myers wrote:
> On Fri, 5 Dec 2014, Paul Eggert wrote:
>
> > On 12/05/2014 12:26 PM, Rich Felker wrote:
> > > If N is the size of an actual allocated object, 2*N should not be able
> > > to overflow. If it can, it means you already have a situation where an
> > > object is so large that legal pointer subtractions overflow ptrdiff_t
> > No, because the array elements are of type struct printf_spec, which is
> > several bytes in size. So even if the number of bytes in the array exceeds
> > PTRDIFF_MAX by a factor of (say) eight, subtracting addresses of array
> > elements won't overflow.
>
> Such subtraction of pointers differing by more than SIZE_MAX / 2 bytes
> does not actually work in GCC (it does a subtraction, which overflows,
> then a division - and that approach is fine for all normal arguments).
>
> I think malloc should in principle disallow allocations of more than
> SIZE_MAX / 2 bytes, but right now it doesn't, and I suspect a change would
> break compatibility for various existing applications that expect to do
> > 2GB allocations on 32-bit systems.
Yes, malloc (and mmap and shmget/shmat) should disallow allocations
larger than SIZE_MAX/2 for exactly this reason. I doubt it would break
things fixing it. Such a large malloc is unlikely to work on 32-bit
systems anyway, given than 1GB is taken by the kernel and the
placement of the main program, stack,dynamic linker, and shared libs
already fragments the address space a bit. You might get lucky if it
happens very early in program lifetime in a program without lots of
libs, but I think relying on >2GB malloc on a 32-bit system is already
fragile.
Rich
On Fri, Dec 05, 2014 at 05:43:41PM +0100, Florian Weimer wrote:
> This fell through the cracks. I took Jeff Law's patch (which we
> carry as a local patch in Fedora and downstream), compressed the
> bug23-3.c test case, and added Joseph's test case from the bug as
> bug23-4.c.
>
> Tested on x86_64-redhat-linux-gnu, with no regressions.
>
> --
> Florian Weimer / Red Hat Product Security
> >From 3fcae31c646f9419b5201c9189f961487f2b6743 Mon Sep 17 00:00:00 2001
> From: Jeff Law <law@redhat.com>
> Date: Fri, 5 Dec 2014 15:49:34 +0100
> Subject: [PATCH] CVE-2012-3406: Stack overflow in vfprintf [BZ #16617]
>
> A larger number of format specifiers coudld cause a stack overflow,
> potentially allowing to bypass _FORTIFY_SOURCE format string
> protection.
>
snip
> @@ -1722,10 +1728,25 @@ do_positional:
> {
> /* Extend the array of format specifiers. */
> struct printf_spec *old = specs;
> - specs = extend_alloca (specs, nspecs_size, 2 * nspecs_size);
> + if (__libc_use_alloca (2 * nspecs_size))
> + specs = extend_alloca (specs, nspecs_size, 2 * nspecs_size);
> + else
> + {
> + nspecs_size *= 2;
> + specs = malloc (nspecs_size);
No check to return with errno=ENOMEM?
> + }
>
> /* Copy the old array's elements to the new space. */
> memmove (specs, old, nspecs * sizeof (*specs));
> +
> + /* If we had previously malloc'd space for SPECS, then
> + release it after the copy is complete. */
> + if (specs_malloced)
> + free (old);
> +
> + /* Now set SPECS_MALLOCED if needed. */
> + if (!__libc_use_alloca (nspecs_size))
> + specs_malloced = true;
> }
>
> /* Parse the format specifier. */
> @@ -2046,6 +2067,8 @@ do_positional:
> }
>
> all_done:
> + if (specs_malloced)
> + free (specs);
> if (__glibc_unlikely (args_malloced != NULL))
> free (args_malloced);
> if (__glibc_unlikely (workstart != NULL))
> --
> 1.9.3
>
Otherwise I am ok with that change, I would drop extend_alloca as code
is simpler (and bump initial size to 126).
Performance-wise a memmove dominates if realloc that does not move it could be faster.
Only problem with that is printf in signal handlers but I do not belive that somebody
needs that much specifiers.
On 12/05/2014 06:01 PM, Joseph Myers wrote:
> On Fri, 5 Dec 2014, Florian Weimer wrote:
>
>> This fell through the cracks. I took Jeff Law's patch (which we carry as a
>> local patch in Fedora and downstream), compressed the bug23-3.c test case, and
>> added Joseph's test case from the bug as bug23-4.c.
>
> What's your view of the other possible overflows there that Paul Eggert
> mentioned in <https://sourceware.org/ml/libc-alpha/2012-02/msg00102.html>?
> I think nspecs * sizeof (*specs) is always OK (that's the size of an
> object that's already been allocated), but 2 * nspecs_size might not be
> (if it can't overflow in practice, that's an accident to do with the
> size of struct printf_spec, the particular sequence of allocation sizes
> and how much memory it's actually possible to allocate on existing
> systems, rather than because the code is sensible to keep as-is without a
> check on that multiplication).
On 32-bit systems, the largest possible size is 3221225472, which
corresponds to 67108864 format specifiers. At four characters per
format specifier, this means that roughly 80% of the 32-bit address
space need to be allocated before the overflow occurs, in two fairly
large chunks. It seems rather unlikely this is possible (it certainly
requires a 32-bit kernel). In my test, it's not.
I need to add the NULL check anyway, as Ondřej pointed, so I'll resubmit
with both changes included. But I think that both changes are just
hardening, so no new CVE ID is needed.
From 3fcae31c646f9419b5201c9189f961487f2b6743 Mon Sep 17 00:00:00 2001
From: Jeff Law <law@redhat.com>
Date: Fri, 5 Dec 2014 15:49:34 +0100
Subject: [PATCH] CVE-2012-3406: Stack overflow in vfprintf [BZ #16617]
A larger number of format specifiers coudld cause a stack overflow,
potentially allowing to bypass _FORTIFY_SOURCE format string
protection.
2014-12-05 Jeff Law <law@redhat.com>
[BZ #16617]
* stdio-common/vfprintf.c (vfprintf): Allocate large specs array
on the heap. (CVE-2012-3406)
* stdio-common/bug23-2.c, stdio-common/bug23-3.c: New file.
* stdio-common/bug23-4.c: New file. Test case by Joseph Myers.
* stdio-common/Makefile (tests): Add bug23-2, bug23-3, bug23-4.
@@ -10,10 +10,11 @@ Version 2.21
* The following bugs are resolved with this release:
6652, 12926, 13862, 14132, 14138, 14171, 14498, 15215, 15884, 16469,
- 16619, 16740, 16857, 17192, 17266, 17344, 17363, 17370, 17371, 17411,
- 17460, 17475, 17485, 17501, 17506, 17508, 17522, 17555, 17570, 17571,
- 17572, 17573, 17574, 17581, 17582, 17583, 17584, 17585, 17589, 17594,
- 17601, 17608, 17616, 17625, 17633, 17647, 17653, 17664, 17665, 17668.
+ 16617, 16619, 16740, 16857, 17192, 17266, 17344, 17363, 17370, 17371,
+ 17411, 17460, 17475, 17485, 17501, 17506, 17508, 17522, 17555, 17570,
+ 17571, 17572, 17573, 17574, 17581, 17582, 17583, 17584, 17585, 17589,
+ 17594, 17601, 17608, 17616, 17625, 17633, 17647, 17653, 17664, 17665,
+ 17668.
* CVE-2104-7817 The wordexp function could ignore the WRDE_NOCMD flag
under certain input conditions resulting in the execution of a shell for
@@ -57,7 +57,7 @@ tests := tstscanf test_rdwr test-popen tstgetln test-fseek \
bug19 bug19a tst-popen2 scanf13 scanf14 scanf15 bug20 bug21 bug22 \
scanf16 scanf17 tst-setvbuf1 tst-grouping bug23 bug24 \
bug-vfprintf-nargs tst-long-dbl-fphex tst-fphex-wide tst-sprintf3 \
- bug25 tst-printf-round bug26
+ bug25 tst-printf-round bug23-2 bug23-3 bug23-4
test-srcs = tst-unbputc tst-printf
new file mode 100644
@@ -0,0 +1,70 @@
+#include <stdio.h>
+#include <string.h>
+#include <stdlib.h>
+
+static const char expected[] = "\
+\n\
+a\n\
+abbcd55\
+\n\
+a\n\
+abbcd55\
+\n\
+a\n\
+abbcd55\
+\n\
+a\n\
+abbcd55\
+\n\
+a\n\
+abbcd55\
+\n\
+a\n\
+abbcd55\
+\n\
+a\n\
+abbcd55\
+\n\
+a\n\
+abbcd55\
+\n\
+a\n\
+abbcd55\
+\n\
+a\n\
+abbcd55\
+\n\
+a\n\
+abbcd55\
+\n\
+a\n\
+abbcd55\
+\n\
+a\n\
+abbcd55%%%%%%%%%%%%%%%%%%%%%%%%%%\n";
+
+static int
+do_test (void)
+{
+ char *buf = malloc (strlen (expected) + 1);
+ snprintf (buf, strlen (expected) + 1,
+ "\n%1$s\n" "%1$s" "%2$s" "%2$s" "%3$s" "%4$s" "%5$d" "%5$d"
+ "\n%1$s\n" "%1$s" "%2$s" "%2$s" "%3$s" "%4$s" "%5$d" "%5$d"
+ "\n%1$s\n" "%1$s" "%2$s" "%2$s" "%3$s" "%4$s" "%5$d" "%5$d"
+ "\n%1$s\n" "%1$s" "%2$s" "%2$s" "%3$s" "%4$s" "%5$d" "%5$d"
+ "\n%1$s\n" "%1$s" "%2$s" "%2$s" "%3$s" "%4$s" "%5$d" "%5$d"
+ "\n%1$s\n" "%1$s" "%2$s" "%2$s" "%3$s" "%4$s" "%5$d" "%5$d"
+ "\n%1$s\n" "%1$s" "%2$s" "%2$s" "%3$s" "%4$s" "%5$d" "%5$d"
+ "\n%1$s\n" "%1$s" "%2$s" "%2$s" "%3$s" "%4$s" "%5$d" "%5$d"
+ "\n%1$s\n" "%1$s" "%2$s" "%2$s" "%3$s" "%4$s" "%5$d" "%5$d"
+ "\n%1$s\n" "%1$s" "%2$s" "%2$s" "%3$s" "%4$s" "%5$d" "%5$d"
+ "\n%1$s\n" "%1$s" "%2$s" "%2$s" "%3$s" "%4$s" "%5$d" "%5$d"
+ "\n%1$s\n" "%1$s" "%2$s" "%2$s" "%3$s" "%4$s" "%5$d" "%5$d"
+ "\n%1$s\n" "%1$s" "%2$s" "%2$s" "%3$s" "%4$s" "%5$d" "%5$d"
+ "%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%\n",
+ "a", "b", "c", "d", 5);
+ return strcmp (buf, expected) != 0;
+}
+
+#define TEST_FUNCTION do_test ()
+#include "../test-skeleton.c"
new file mode 100644
@@ -0,0 +1,50 @@
+#include <stdio.h>
+#include <string.h>
+#include <stdlib.h>
+
+int
+do_test (void)
+{
+ size_t instances = 16384;
+#define X0 "\n%1$s\n" "%1$s" "%2$s" "%2$s" "%3$s" "%4$s" "%5$d" "%5$d"
+ const char *item = "\na\nabbcd55";
+#define X3 X0 X0 X0 X0 X0 X0 X0 X0
+#define X6 X3 X3 X3 X3 X3 X3 X3 X3
+#define X9 X6 X6 X6 X6 X6 X6 X6 X6
+#define X12 X9 X9 X9 X9 X9 X9 X9 X9
+#define X14 X12 X12 X12 X12
+#define TRAILER "%%%%%%%%%%%%%%%%%%%%%%%%%%"
+#define TRAILER2 TRAILER TRAILER
+ size_t length = instances * strlen (item) + strlen (TRAILER) + 1;
+
+ char *buf = malloc (length + 1);
+ snprintf (buf, length + 1,
+ X14 TRAILER2 "\n",
+ "a", "b", "c", "d", 5);
+
+ const char *p = buf;
+ size_t i;
+ for (i = 0; i < instances; ++i)
+ {
+ const char *expected;
+ for (expected = item; *expected; ++expected)
+ {
+ if (*p != *expected)
+ {
+ printf ("mismatch at offset %zu (%zu): expected %d, got %d\n",
+ (size_t) (p - buf), i, *expected & 0xFF, *p & 0xFF);
+ return 1;
+ }
+ ++p;
+ }
+ }
+ if (strcmp (p, TRAILER "\n") != 0)
+ {
+ printf ("mismatch at trailer: [%s]\n", p);
+ return 1;
+ }
+ free (buf);
+ return 0;
+}
+#define TEST_FUNCTION do_test ()
+#include "../test-skeleton.c"
new file mode 100644
@@ -0,0 +1,31 @@
+#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;
+}
@@ -263,6 +263,12 @@ vfprintf (FILE *s, const CHAR_T *format, va_list ap)
/* For the argument descriptions, which may be allocated on the heap. */
void *args_malloced = NULL;
+ /* For positional argument handling. */
+ struct printf_spec *specs;
+
+ /* Track if we malloced the SPECS array and thus must free it. */
+ bool specs_malloced = false;
+
/* This table maps a character into a number representing a
class. In each step there is a destination label for each
class. */
@@ -1679,8 +1685,8 @@ do_positional:
size_t nspecs = 0;
/* A more or less arbitrary start value. */
size_t nspecs_size = 32 * sizeof (struct printf_spec);
- struct printf_spec *specs = alloca (nspecs_size);
+ specs = alloca (nspecs_size);
/* The number of arguments the format string requests. This will
determine the size of the array needed to store the argument
attributes. */
@@ -1722,10 +1728,25 @@ do_positional:
{
/* Extend the array of format specifiers. */
struct printf_spec *old = specs;
- specs = extend_alloca (specs, nspecs_size, 2 * nspecs_size);
+ if (__libc_use_alloca (2 * nspecs_size))
+ specs = extend_alloca (specs, nspecs_size, 2 * nspecs_size);
+ else
+ {
+ nspecs_size *= 2;
+ specs = malloc (nspecs_size);
+ }
/* Copy the old array's elements to the new space. */
memmove (specs, old, nspecs * sizeof (*specs));
+
+ /* If we had previously malloc'd space for SPECS, then
+ release it after the copy is complete. */
+ if (specs_malloced)
+ free (old);
+
+ /* Now set SPECS_MALLOCED if needed. */
+ if (!__libc_use_alloca (nspecs_size))
+ specs_malloced = true;
}
/* Parse the format specifier. */
@@ -2046,6 +2067,8 @@ do_positional:
}
all_done:
+ if (specs_malloced)
+ free (specs);
if (__glibc_unlikely (args_malloced != NULL))
free (args_malloced);
if (__glibc_unlikely (workstart != NULL))
--
1.9.3