Re: Thread stack and heap caches - CVE-2019-1010024

[Vinay Kumar <vinay dot m dot engg at gmail dot com>]

Hi Florian,

Thanks for the feed back.

FYI,
I had posted the new patch with added glibc configure option
"--with-aslr" which we will not call "get_cached_stack" function.
Also I have posted the output with the testcase from bugzilla.

Link : https://sourceware.org/ml/libc-alpha/2019-11/msg00349.html
Patch link : https://sourceware.org/ml/libc-alpha/2019-11/msg00349/aslr_glibc.patch

Will verify your feedback with my new patch and update you on the same.

Thanks and regards,
Vinay

Regards,
Vinay

On Mon, Nov 25, 2019 at 11:40 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Vinay Kumar:
>
> > Hi,
> >
> > Regarding bug related to Thread stack and heap caches (CVE-2019-1010024).
> > https://sourceware.org/bugzilla/show_bug.cgi?id=22852
> >
> >>> One way to harden is to use a tunable for a thread stack cache, and set that to zero.
> > Below change in glibc allocatestack.c file gives the expected output
> > with test case. Verified on x86_64 target.
> > =======================================================
> > --- a/nptl/allocatestack.c
> > +++ b/nptl/allocatestack.c
> > @@ -186,6 +186,7 @@ get_cached_stack (size_t *sizep, void **memp)
> >        struct pthread *curr;
> >
> >        curr = list_entry (entry, struct pthread, list);
> > +      curr->stackblock_size = 0;
> >        if (FREE_P (curr) && curr->stackblock_size >= size)
> >         {
> >           if (curr->stackblock_size == size)
> > =======================================================
>
> This will just cause crashes (abort in free_statcks).
>
> I tried to emulate the effect with this program:
>
> #include <err.h>
> #include <errno.h>
> #include <pthread.h>
> #include <stddef.h>
> #include <stdint.h>
> #include <stdio.h>
>
> static void *
> thread (void *closure)
> {
>   uintptr_t *pp = closure;
>   *pp = (uintptr_t) &pp;
>   return NULL;
> }
>
> int
> main (void)
> {
>   pthread_attr_t attr;
>   int ret = pthread_attr_init (&attr);
>   if (ret != 0)
>     {
>       errno = ret;
>       err (1, "pthread_attr_init");
>     }
>   ret = pthread_attr_setstacksize (&attr, 128 * 1024 * 1024);
>   if (ret != 0)
>     {
>       errno = ret;
>       err (1, "pthread_attr_setstacksize");
>     }
>
>   for (int i = 0; i < 20; ++i)
>     {
>       pthread_t thr;
>       uintptr_t ptr;
>       ret = pthread_create (&thr, &attr, thread, &ptr);
>       if (ret != 0)
>         {
>           errno = ret;
>           err (1, "pthread_create");
>         }
>       ret = pthread_join (thr, NULL);
>       if (ret != 0)
>         {
>           errno = ret;
>           err (1, "pthread_join");
>         }
>       printf ("%p\n", (void *) ptr);
>     }
> }
>
> Its stack size is so large that the stack is never cached.  If you run
> it with strace, you will see that mmap and munmap is called for each
> iteration.
>
> As I suspected, it prints the same address again and again because the
> kernel does NOT randomize mappings.  Until that happens, there is not
> much value in disabling the stack cache.
>
> Thanks,
> Florian
>