This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 0/3] explicit_bzero v5
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.