Re: [PATCH 1/2] glibc: CVE-2015-1472: wscanf allocates too little memory

Re: [PATCH 1/2] glibc: CVE-2015-1472: wscanf allocates too little memory

[Haris Okanovic]

On 05/07/2015 06:19 PM, Haris Okanovic wrote:
> Backport Paul Pluzhnikov's glibc patch for CVE-2015-1472:
>
> Under certain conditions wscanf can allocate too little memory for the
> to-be-scanned arguments and overflow the allocated buffer.  The
> implementation now correctly computes the required buffer size when
> using malloc.
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=16618
>
> Signed-off-by: Haris Okanovic <haris.okanovic@ni.com>
> Signed-off-by: Ken Sharp <ken.sharp@ni.com>
> Reviewed-by: Rich Tollerton <rich.tollerton@ni.com>
> ---

Note that this patch is to apply to the Dizzy branch of 
openembedded-core (glibc 2.20). It might cleanly apply to other branches 
also using glibc 2.20, but I've only tested with Dizzy.

CVE-2015-1472 is fixed in glibc 2.21 and later.

Thanks,
Haris

Re: [PATCH 1/2] glibc: CVE-2015-1472: wscanf allocates too little memory

[akuster808]

Haris,

thanks. I will stage this on my dizzy next branch.

please include [Dizzy/fido] in the subject line if a patch meant for a 
specific release. it will help route patches.
regards,
Armin

On 05/08/2015 08:47 AM, Haris Okanovic wrote:
> On 05/07/2015 06:19 PM, Haris Okanovic wrote:
>> Backport Paul Pluzhnikov's glibc patch for CVE-2015-1472:
>>
>> Under certain conditions wscanf can allocate too little memory for the
>> to-be-scanned arguments and overflow the allocated buffer.  The
>> implementation now correctly computes the required buffer size when
>> using malloc.
>>
>> https://sourceware.org/bugzilla/show_bug.cgi?id=16618
>>
>> Signed-off-by: Haris Okanovic <haris.okanovic@ni.com>
>> Signed-off-by: Ken Sharp <ken.sharp@ni.com>
>> Reviewed-by: Rich Tollerton <rich.tollerton@ni.com>
>> ---
>
> Note that this patch is to apply to the Dizzy branch of
> openembedded-core (glibc 2.20). It might cleanly apply to other branches
> also using glibc 2.20, but I've only tested with Dizzy.
>
> CVE-2015-1472 is fixed in glibc 2.21 and later.
>
> Thanks,
> Haris

Re: [PATCH 2/2] glibc: CVE-2015-1781: resolv/nss_dns/dns-host.c buffer overflow

[Haris Okanovic]

On 05/07/2015 06:19 PM, Haris Okanovic wrote:
> Backport Arjun Shankar's patch for CVE-2015-1781:
>
> A buffer overflow flaw was found in the way glibc's gethostbyname_r() and
> other related functions computed the size of a buffer when passed a
> misaligned buffer as input. An attacker able to make an application call
> any of these functions with a misaligned buffer could use this flaw to
> crash the application or, potentially, execute arbitrary code with the
> permissions of the user running the application.
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=18287
>
> Signed-off-by: Haris Okanovic <haris.okanovic@ni.com>
> Signed-off-by: Ken Sharp <ken.sharp@ni.com>
> Reviewed-by: Rich Tollerton <rich.tollerton@ni.com>
> ---

Note that this patch is to apply to the Dizzy branch of 
openembedded-core (glibc 2.20). It might cleanly apply to other branches 
also using glibc 2.20, but I've only tested with Dizzy.

CVE-2015-1781 is fixed in glibc 2.22 and later.

Thanks,
Haris

Re: [PATCH 2/2] glibc: CVE-2015-1781: resolv/nss_dns/dns-host.c buffer overflow

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 407 bytes --]

On 8 May 2015 at 16:50, Haris Okanovic <haris.okanovic@ni.com> wrote:

> Note that this patch is to apply to the Dizzy branch of openembedded-core (
> glibc 2.20). It might cleanly apply to other branches also using glibc
> 2.20, but I've only tested with Dizzy.
>
> CVE-2015-1781 is fixed in glibc 2.22 and later.
>

Will you be able to port this to master which is currently glibc 2.21?

Ross

[-- Attachment #2: Type: text/html, Size: 889 bytes --]

Re: [PATCH 2/2] glibc: CVE-2015-1781: resolv/nss_dns/dns-host.c buffer overflow

[Haris Okanovic]

On 05/14/2015 03:39 PM, Burton, Ross wrote:
> Will you be able to port this to master which is currently glibc 2.21?

Sure. I'll post a second patch to oe-core for master (glibc 2.21) once I 
test it out. It'll be the same .patch file for glibc's source, but a 
different change in the bb recipe.

The original patch I sent earlier still applies to other branches that 
use glibc 2.20. E.g. Dizzy.

Haris

[PATCH 1/2] glibc: CVE-2015-1472: wscanf allocates too little memory

[Haris Okanovic]

Backport Paul Pluzhnikov's glibc patch for CVE-2015-1472:

Under certain conditions wscanf can allocate too little memory for the
to-be-scanned arguments and overflow the allocated buffer.  The
implementation now correctly computes the required buffer size when
using malloc.

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

Signed-off-by: Haris Okanovic <haris.okanovic@ni.com>
Signed-off-by: Ken Sharp <ken.sharp@ni.com>
Reviewed-by: Rich Tollerton <rich.tollerton@ni.com>
---
Natinst-CAR-ID: 518552
Natinst-ReviewBoard-ID: 96712
---
 ...5-1472-wscanf-allocates-too-little-memory.patch | 127 +++++++++++++++++++++
 meta/recipes-core/glibc/glibc_2.20.bb              |   1 +
 2 files changed, 128 insertions(+)
 create mode 100644 meta/recipes-core/glibc/glibc/CVE-2015-1472-wscanf-allocates-too-little-memory.patch

diff --git a/meta/recipes-core/glibc/glibc/CVE-2015-1472-wscanf-allocates-too-little-memory.patch b/meta/recipes-core/glibc/glibc/CVE-2015-1472-wscanf-allocates-too-little-memory.patch
new file mode 100644
index 0000000..4ffd609
--- /dev/null
+++ b/meta/recipes-core/glibc/glibc/CVE-2015-1472-wscanf-allocates-too-little-memory.patch
@@ -0,0 +1,127 @@
+From 5bd80bfe9ca0d955bfbbc002781bc7b01b6bcb06 Mon Sep 17 00:00:00 2001
+From: Paul Pluzhnikov <ppluzhnikov@google.com>
+Date: Fri, 6 Feb 2015 00:30:42 -0500
+Subject: [PATCH] CVE-2015-1472: wscanf allocates too little memory
+
+BZ #16618
+
+Under certain conditions wscanf can allocate too little memory for the
+to-be-scanned arguments and overflow the allocated buffer.  The
+implementation now correctly computes the required buffer size when
+using malloc.
+
+A regression test was added to tst-sscanf.
+
+Upstream-Status: Backport
+https://sourceware.org/bugzilla/show_bug.cgi?id=16618
+---
+ stdio-common/tst-sscanf.c | 33 +++++++++++++++++++++++++++++++++
+ stdio-common/vfscanf.c    | 12 ++++++------
+ 2 files changed, 39 insertions(+), 6 deletions(-)
+
+diff --git a/stdio-common/tst-sscanf.c b/stdio-common/tst-sscanf.c
+index aece3f2f290088b2c08441cf85f2b915a61b9789..8a2eb9e39c4752a30941753d7f0325c2aa352fd1 100644
+--- a/stdio-common/tst-sscanf.c
++++ b/stdio-common/tst-sscanf.c
+@@ -226,12 +226,45 @@ main (void)
+ 	  result = 1;
+ 	}
+       else if (ret == 2 && c != double_tests2[i].residual)
+ 	{
+ 	  printf ("double_tests2[%d] stopped at '%c' != '%c'\n",
+ 		  i, c, double_tests2[i].residual);
+ 	  result = 1;
+ 	}
+     }
+ 
++  /* BZ #16618
++     The test will segfault during SSCANF if the buffer overflow
++     is not fixed.  The size of `s` is such that it forces the use
++     of malloc internally and this triggers the incorrect computation.
++     Thus the value for SIZE is arbitrariy high enough that malloc
++     is used.  */
++  {
++#define SIZE 131072
++    CHAR *s = malloc ((SIZE + 1) * sizeof (*s));
++    if (s == NULL)
++      abort ();
++    for (size_t i = 0; i < SIZE; i++)
++      s[i] = L('0');
++    s[SIZE] = L('\0');
++    int i = 42;
++    /* Scan multi-digit zero into `i`.  */
++    if (SSCANF (s, L("%d"), &i) != 1)
++      {
++	printf ("FAIL: bug16618: SSCANF did not read one input item.\n");
++	result = 1;
++      }
++    if (i != 0)
++      {
++	printf ("FAIL: bug16618: Value of `i` was not zero as expected.\n");
++	result = 1;
++      }
++    free (s);
++    if (result != 1)
++      printf ("PASS: bug16618: Did not crash.\n");
++#undef SIZE
++  }
++
++
+   return result;
+ }
+diff --git a/stdio-common/vfscanf.c b/stdio-common/vfscanf.c
+index cd129a81dee57e5e06ccb0e676e0de3fd52469ca..0e204e7b326d848716222f40b5b82b8256ed1b77 100644
+--- a/stdio-common/vfscanf.c
++++ b/stdio-common/vfscanf.c
+@@ -265,42 +265,42 @@ _IO_vfscanf_internal (_IO_FILE *s, const char *format, _IO_va_list argptr,
+   CHAR_T *wp = NULL;		/* Workspace.  */
+   size_t wpmax = 0;		/* Maximal size of workspace.  */
+   size_t wpsize;		/* Currently used bytes in workspace.  */
+   bool use_malloc = false;
+ #define ADDW(Ch)							    \
+   do									    \
+     {									    \
+       if (__glibc_unlikely (wpsize == wpmax))				      \
+ 	{								    \
+ 	  CHAR_T *old = wp;						    \
+-	  size_t newsize = (UCHAR_MAX + 1 > 2 * wpmax			    \
+-			    ? UCHAR_MAX + 1 : 2 * wpmax);		    \
+-	  if (use_malloc || !__libc_use_alloca (newsize))		    \
++	  bool fits = __glibc_likely (wpmax <= SIZE_MAX / sizeof (CHAR_T) / 2); \
++	  size_t wpneed = MAX (UCHAR_MAX + 1, 2 * wpmax);		    \
++	  size_t newsize = fits ? wpneed * sizeof (CHAR_T) : SIZE_MAX;	    \
++	  if (!__libc_use_alloca (newsize))				    \
+ 	    {								    \
+ 	      wp = realloc (use_malloc ? wp : NULL, newsize);		    \
+ 	      if (wp == NULL)						    \
+ 		{							    \
+ 		  if (use_malloc)					    \
+ 		    free (old);						    \
+ 		  done = EOF;						    \
+ 		  goto errout;						    \
+ 		}							    \
+ 	      if (! use_malloc)						    \
+ 		MEMCPY (wp, old, wpsize);				    \
+-	      wpmax = newsize;						    \
++	      wpmax = wpneed;						    \
+ 	      use_malloc = true;					    \
+ 	    }								    \
+ 	  else								    \
+ 	    {								    \
+ 	      size_t s = wpmax * sizeof (CHAR_T);			    \
+-	      wp = (CHAR_T *) extend_alloca (wp, s,			    \
+-					     newsize * sizeof (CHAR_T));    \
++	      wp = (CHAR_T *) extend_alloca (wp, s, newsize);		    \
+ 	      wpmax = s / sizeof (CHAR_T);				    \
+ 	      if (old != NULL)						    \
+ 		MEMCPY (wp, old, wpsize);				    \
+ 	    }								    \
+ 	}								    \
+       wp[wpsize++] = (Ch);						    \
+     }									    \
+   while (0)
+ 
+ #ifdef __va_copy
+-- 
+2.2.2
+
diff --git a/meta/recipes-core/glibc/glibc_2.20.bb b/meta/recipes-core/glibc/glibc_2.20.bb
index 3277f7a..e3427dd 100644
--- a/meta/recipes-core/glibc/glibc_2.20.bb
+++ b/meta/recipes-core/glibc/glibc_2.20.bb
@@ -46,6 +46,7 @@ CVEPATCHES = "\
         file://CVE-2014-7817-wordexp-fails-to-honour-WRDE_NOCMD.patch \
         file://CVE-2012-3406-Stack-overflow-in-vfprintf-BZ-16617.patch \
         file://CVE-2014-9402_endless-loop-in-getaddr_r.patch \
+        file://CVE-2015-1472-wscanf-allocates-too-little-memory.patch \
     "
 LIC_FILES_CHKSUM = "file://LICENSES;md5=e9a558e243b36d3209f380deb394b213 \
       file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
-- 
2.2.2

Re: [PATCH 1/2] glibc: CVE-2015-1472: wscanf allocates too little memory

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 7036 bytes --]

this is ok

> On May 8, 2015, at 7:28 AM, Haris Okanovic <haris.okanovic@ni.com> wrote:
> 
> Backport Paul Pluzhnikov's glibc patch for CVE-2015-1472:
> 
> Under certain conditions wscanf can allocate too little memory for the
> to-be-scanned arguments and overflow the allocated buffer.  The
> implementation now correctly computes the required buffer size when
> using malloc.
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=16618
> 
> Signed-off-by: Haris Okanovic <haris.okanovic@ni.com>
> Signed-off-by: Ken Sharp <ken.sharp@ni.com>
> Reviewed-by: Rich Tollerton <rich.tollerton@ni.com>
> ---
> Natinst-CAR-ID: 518552
> Natinst-ReviewBoard-ID: 96712
> ---
> ...5-1472-wscanf-allocates-too-little-memory.patch | 127 +++++++++++++++++++++
> meta/recipes-core/glibc/glibc_2.20.bb              |   1 +
> 2 files changed, 128 insertions(+)
> create mode 100644 meta/recipes-core/glibc/glibc/CVE-2015-1472-wscanf-allocates-too-little-memory.patch
> 
> diff --git a/meta/recipes-core/glibc/glibc/CVE-2015-1472-wscanf-allocates-too-little-memory.patch b/meta/recipes-core/glibc/glibc/CVE-2015-1472-wscanf-allocates-too-little-memory.patch
> new file mode 100644
> index 0000000..4ffd609
> --- /dev/null
> +++ b/meta/recipes-core/glibc/glibc/CVE-2015-1472-wscanf-allocates-too-little-memory.patch
> @@ -0,0 +1,127 @@
> +From 5bd80bfe9ca0d955bfbbc002781bc7b01b6bcb06 Mon Sep 17 00:00:00 2001
> +From: Paul Pluzhnikov <ppluzhnikov@google.com>
> +Date: Fri, 6 Feb 2015 00:30:42 -0500
> +Subject: [PATCH] CVE-2015-1472: wscanf allocates too little memory
> +
> +BZ #16618
> +
> +Under certain conditions wscanf can allocate too little memory for the
> +to-be-scanned arguments and overflow the allocated buffer.  The
> +implementation now correctly computes the required buffer size when
> +using malloc.
> +
> +A regression test was added to tst-sscanf.
> +
> +Upstream-Status: Backport
> +https://sourceware.org/bugzilla/show_bug.cgi?id=16618
> +---
> + stdio-common/tst-sscanf.c | 33 +++++++++++++++++++++++++++++++++
> + stdio-common/vfscanf.c    | 12 ++++++------
> + 2 files changed, 39 insertions(+), 6 deletions(-)
> +
> +diff --git a/stdio-common/tst-sscanf.c b/stdio-common/tst-sscanf.c
> +index aece3f2f290088b2c08441cf85f2b915a61b9789..8a2eb9e39c4752a30941753d7f0325c2aa352fd1 100644
> +--- a/stdio-common/tst-sscanf.c
> ++++ b/stdio-common/tst-sscanf.c
> +@@ -226,12 +226,45 @@ main (void)
> + 	  result = 1;
> + 	}
> +       else if (ret == 2 && c != double_tests2[i].residual)
> + 	{
> + 	  printf ("double_tests2[%d] stopped at '%c' != '%c'\n",
> + 		  i, c, double_tests2[i].residual);
> + 	  result = 1;
> + 	}
> +     }
> +
> ++  /* BZ #16618
> ++     The test will segfault during SSCANF if the buffer overflow
> ++     is not fixed.  The size of `s` is such that it forces the use
> ++     of malloc internally and this triggers the incorrect computation.
> ++     Thus the value for SIZE is arbitrariy high enough that malloc
> ++     is used.  */
> ++  {
> ++#define SIZE 131072
> ++    CHAR *s = malloc ((SIZE + 1) * sizeof (*s));
> ++    if (s == NULL)
> ++      abort ();
> ++    for (size_t i = 0; i < SIZE; i++)
> ++      s[i] = L('0');
> ++    s[SIZE] = L('\0');
> ++    int i = 42;
> ++    /* Scan multi-digit zero into `i`.  */
> ++    if (SSCANF (s, L("%d"), &i) != 1)
> ++      {
> ++	printf ("FAIL: bug16618: SSCANF did not read one input item.\n");
> ++	result = 1;
> ++      }
> ++    if (i != 0)
> ++      {
> ++	printf ("FAIL: bug16618: Value of `i` was not zero as expected.\n");
> ++	result = 1;
> ++      }
> ++    free (s);
> ++    if (result != 1)
> ++      printf ("PASS: bug16618: Did not crash.\n");
> ++#undef SIZE
> ++  }
> ++
> ++
> +   return result;
> + }
> +diff --git a/stdio-common/vfscanf.c b/stdio-common/vfscanf.c
> +index cd129a81dee57e5e06ccb0e676e0de3fd52469ca..0e204e7b326d848716222f40b5b82b8256ed1b77 100644
> +--- a/stdio-common/vfscanf.c
> ++++ b/stdio-common/vfscanf.c
> +@@ -265,42 +265,42 @@ _IO_vfscanf_internal (_IO_FILE *s, const char *format, _IO_va_list argptr,
> +   CHAR_T *wp = NULL;		/* Workspace.  */
> +   size_t wpmax = 0;		/* Maximal size of workspace.  */
> +   size_t wpsize;		/* Currently used bytes in workspace.  */
> +   bool use_malloc = false;
> + #define ADDW(Ch)							    \
> +   do									    \
> +     {									    \
> +       if (__glibc_unlikely (wpsize == wpmax))				      \
> + 	{								    \
> + 	  CHAR_T *old = wp;						    \
> +-	  size_t newsize = (UCHAR_MAX + 1 > 2 * wpmax			    \
> +-			    ? UCHAR_MAX + 1 : 2 * wpmax);		    \
> +-	  if (use_malloc || !__libc_use_alloca (newsize))		    \
> ++	  bool fits = __glibc_likely (wpmax <= SIZE_MAX / sizeof (CHAR_T) / 2); \
> ++	  size_t wpneed = MAX (UCHAR_MAX + 1, 2 * wpmax);		    \
> ++	  size_t newsize = fits ? wpneed * sizeof (CHAR_T) : SIZE_MAX;	    \
> ++	  if (!__libc_use_alloca (newsize))				    \
> + 	    {								    \
> + 	      wp = realloc (use_malloc ? wp : NULL, newsize);		    \
> + 	      if (wp == NULL)						    \
> + 		{							    \
> + 		  if (use_malloc)					    \
> + 		    free (old);						    \
> + 		  done = EOF;						    \
> + 		  goto errout;						    \
> + 		}							    \
> + 	      if (! use_malloc)						    \
> + 		MEMCPY (wp, old, wpsize);				    \
> +-	      wpmax = newsize;						    \
> ++	      wpmax = wpneed;						    \
> + 	      use_malloc = true;					    \
> + 	    }								    \
> + 	  else								    \
> + 	    {								    \
> + 	      size_t s = wpmax * sizeof (CHAR_T);			    \
> +-	      wp = (CHAR_T *) extend_alloca (wp, s,			    \
> +-					     newsize * sizeof (CHAR_T));    \
> ++	      wp = (CHAR_T *) extend_alloca (wp, s, newsize);		    \
> + 	      wpmax = s / sizeof (CHAR_T);				    \
> + 	      if (old != NULL)						    \
> + 		MEMCPY (wp, old, wpsize);				    \
> + 	    }								    \
> + 	}								    \
> +       wp[wpsize++] = (Ch);						    \
> +     }									    \
> +   while (0)
> +
> + #ifdef __va_copy
> +--
> +2.2.2
> +
> diff --git a/meta/recipes-core/glibc/glibc_2.20.bb b/meta/recipes-core/glibc/glibc_2.20.bb
> index 3277f7a..e3427dd 100644
> --- a/meta/recipes-core/glibc/glibc_2.20.bb
> +++ b/meta/recipes-core/glibc/glibc_2.20.bb
> @@ -46,6 +46,7 @@ CVEPATCHES = "\
>         file://CVE-2014-7817-wordexp-fails-to-honour-WRDE_NOCMD.patch \
>         file://CVE-2012-3406-Stack-overflow-in-vfprintf-BZ-16617.patch \
>         file://CVE-2014-9402_endless-loop-in-getaddr_r.patch \
> +        file://CVE-2015-1472-wscanf-allocates-too-little-memory.patch \
>     "
> LIC_FILES_CHKSUM = "file://LICENSES;md5=e9a558e243b36d3209f380deb394b213 \
>       file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
> --
> 2.2.2
> 
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]