From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 59580 invoked by alias); 16 Nov 2016 21:38:17 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 59568 invoked by uid 89); 16 Nov 2016 21:38:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=won, secure, perfect X-HELO: zimbra.cs.ucla.edu Subject: Re: [PATCH 0/3] explicit_bzero v5 To: Zack Weinberg , Florian Weimer References: <20161115155509.12692-1-zackw@panix.com> <677c23f1-d10a-890d-b875-039d32a3d228@cs.ucla.edu> <03bf455b-7dc9-663b-a748-8f1da9cfcfd3@cs.ucla.edu> <388972da-c60c-6314-b39d-db5fc818fdb8@redhat.com> <545c2830-c00c-7eb9-65c0-cb8042a5069d@panix.com> Cc: GNU C Library , Carlos O'Donell , "Michael Kerrisk (man-pages)" From: Paul Eggert Message-ID: Date: Wed, 16 Nov 2016 21:38:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <545c2830-c00c-7eb9-65c0-cb8042a5069d@panix.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00596.txt.bz2 On 11/16/2016 06:56 AM, Zack Weinberg wrote: > On 11/15/2016 02:35 PM, Paul Eggert wrote: >> On 11/15/2016 10:54 AM, Zack Weinberg wrote: >>> If the adversary can read the stack at all, I suspect they've >>> already won, no matter what we do. >> That will likely be true in many applications, but not in all. > An adversary who can read the stack has access > to at least one pointer into the executable image (i.e. a return > address) and that is sufficient to walk the entire address space, > including all static data and the complete contents of the heap. Sorry, I'm not following. Typically searching a stack is much cheaper than searching all of address space. ASLR is about increasing the adversary's cost; it is not about creating a perfect defense. If ASLR can force an adversary to search all of address space instead of searching just the stack, then that is a win. Another way to put it: Even if an adversary can obtain the address of one object, that doesn't mean that ASLR is useless thereafter. ASLR can still make it hard for the adversary to obtain the addresses of other objects, and this can still make the program harder to attack overall. So, even if the adversary can read the stack, ASLR can still be useful if the password buffer is on the heap and if no addresses in the stack point to the password buffer. > >> It's worth documenting the issue for applications that put sensitive >> objects in the heap, as they might not expose these object addresses >> to the stack now > How on earth are they to operate on sensitive objects on the heap > without holding their addresses in function-local variables, which one > must assume do from time to time get spilled onto the stack? Yes, one must assume that if one is considering a worst-case compiler. But there are other possibilities. Perhaps the addresses are not spilled in code that calls memset or uses inline code, whereas the addresses do get spilled in the code that calls explicit_bzero. So, in practice, changing C code to call explicit_bzero can create spills that didn't exist before, which means that in practice the machine code can be less secure than before.