vfprintf stack overflow [BZ #16617]
diff mbox

Message ID 5481E0BD.9000203@redhat.com
State New
Headers show

Commit Message

Florian Weimer Dec. 5, 2014, 4:43 p.m. UTC
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

Joseph Myers Dec. 5, 2014, 5:01 p.m. UTC | #1
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.)
Rich Felker Dec. 5, 2014, 8:26 p.m. UTC | #2
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
Paul Eggert Dec. 5, 2014, 10 p.m. UTC | #3
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.
Joseph Myers Dec. 5, 2014, 10:42 p.m. UTC | #4
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.
Rich Felker Dec. 5, 2014, 10:50 p.m. UTC | #5
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
Rich Felker Dec. 5, 2014, 10:55 p.m. UTC | #6
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
Ondřej Bílka Dec. 6, 2014, 1:38 p.m. UTC | #7
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.
Florian Weimer Dec. 8, 2014, 10:55 a.m. UTC | #8
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.

Patch
diff mbox

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