From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-2.8 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_GMAIL_RCVD, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id E6E581F463 for ; Mon, 25 Nov 2019 18:29:54 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; q=dns; s=default; b=WMtP UOl975ek2sZ2CNYBSSM7NhZS2hHiCPGW2271k7FQmEbaRXoJRGuWOGrMrnCKIf4j zs7uzjyRDfjhGGHy+5h5xIeLboQyx3XxD4Gl2jRNYDZbgZ90tROtS1Cdk089rUM6 omn9008yD8dRiuvfXqbDzfTq0PaVsUG8g2EHt4U= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; s=default; bh=9qDKtBpnkK cVaArWxBCFgVa7nwc=; b=KOHhu3HcRzT4O1I4fM4VMh1Ruf35D5ssUr58BGZ/kp PV0pY0u8m9jG1gcQYFf2+dhYGbintajf8ShEPxy4+S5O7riSISa7uDXhyMGDIdpG qGdXBFVfUnID4dkctYVqguNltAXCf5/4iRYotWJbcUEFLwIK/5dtilIUHCm/3yw6 4= Received: (qmail 79871 invoked by alias); 25 Nov 2019 18:29:52 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 79863 invoked by uid 89); 25 Nov 2019 18:29:52 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-qt1-f194.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=//8LNH0WILvS3KY4Wfy5qPlRPy9G+O48pY8CJDLVRgc=; b=Sve4xAqe44lHMZW3S5bU2Q4ZskIuZQIULqYI0kKTHmOV4haItAYdqGM0T0PwWHblNq rxiddcwcVguA2+FFSGzU3cRcUl9h2rZeBJAyNiJ5o48fTgpEeCShN36T4dWNSjqZHn6S 32TLV3ZZSD78vREN90xnjka7ZDL5h6augpnOaKP8PPcBnG/rd92aHlfsluwSluqk7H5d oxB2D/ae2dpMq7fm+bBkhS5N48ESv/KOeFD/Xf9DM9Pm+3W4q2iOs10ntf74tgZ3o+Sc q1wq000wpwd8N24D+KrSUFE+Qqw/00LALr2rsusUdXdUqxOVjKXpQnATnLfXGSjpiCrj BN7Q== MIME-Version: 1.0 References: <87h82rg73m.fsf@oldenburg2.str.redhat.com> In-Reply-To: <87h82rg73m.fsf@oldenburg2.str.redhat.com> From: Vinay Kumar Date: Mon, 25 Nov 2019 23:59:37 +0530 Message-ID: Subject: Re: Thread stack and heap caches - CVE-2019-1010024 To: Florian Weimer Cc: libc-alpha@sourceware.org, carlos@redhat.com Content-Type: text/plain; charset="UTF-8" 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 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 > #include > #include > #include > #include > #include > > 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 >