| Message ID | 5481E0BD.9000203@redhat.com |
|---|---|
| State | New |
| Headers | show |
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. diff --git a/NEWS b/NEWS index 84c1353..fe46941 100644 --- a/NEWS +++ b/NEWS @@ -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 diff --git a/stdio-common/Makefile b/stdio-common/Makefile index 5f8e534..24e8496 100644 --- a/stdio-common/Makefile +++ b/stdio-common/Makefile @@ -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 diff --git a/stdio-common/bug23-2.c b/stdio-common/bug23-2.c new file mode 100644 index 0000000..9e0cfe6 --- /dev/null +++ b/stdio-common/bug23-2.c @@ -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" diff --git a/stdio-common/bug23-3.c b/stdio-common/bug23-3.c new file mode 100644 index 0000000..57c8cef --- /dev/null +++ b/stdio-common/bug23-3.c @@ -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" diff --git a/stdio-common/bug23-4.c b/stdio-common/bug23-4.c new file mode 100644 index 0000000..a478564 --- /dev/null +++ b/stdio-common/bug23-4.c @@ -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; +} diff --git a/stdio-common/vfprintf.c b/stdio-common/vfprintf.c index c4ff833..520b33c 100644 --- a/stdio-common/vfprintf.c +++ b/stdio-common/vfprintf.c @@ -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