Re: [PATCH 0/3] explicit_bzero v5

[Paul Eggert <eggert@cs.ucla.edu>]

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.