This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]