
Hardening C/C++ Programs: Stack Protector - mrich
http://www.productive-cpp.com/hardening-cpp-programs-stack-protector/
======
Retr0spectrum
Note that enabling stack protection is often not enough to completely mitigate
stack smashing attacks if there is a vulnerability in the code.

For example if you can leak the value of the protector somehow, then you can
just replace it with its original value when you smash the stack.

Alternatively, it may be possible to brute-force the stack protector value,
particularly on 32-bit systems where the protector often only has 24 bits of
entropy.

------
alok-g
Would it have been better if the return addresses were put in a separate stack
than the function variables to begin with?

~~~
willvarfar
This is what -fsanitize=safe-stack does in software
[https://clang.llvm.org/docs/SafeStack.html](https://clang.llvm.org/docs/SafeStack.html)
and what the new Mill CPU does in hardware. On the Mill, the return addresses
are on a hardware-managed call stack that cannot be corrupted by the program.

------
slededit
I really don't understand why we _still_ mix our control and data stacks
together. Memory fragmentation made this necessary in the past but we
shouldn't need this anymore.

~~~
AnimalMuppet
It was convenient, when a function returned, to only have to pop one stack
rather than two.

And maybe more than just convenient. Mixing them allows stack smashing bugs,
but it completely eliminates bugs where the control and data stacks get out of
sync.

Which is worse? We don't know, because we don't have decades of experience
with "stack out of sync" attacks.

~~~
slededit
Allowing a bug to hijack the control flow of the program is much worse. To a
limited extent you can do this even with pure data manipulation (function
pointers, if statement inputs etc) but it is much more constrained.

FWIW Web Assembly doesn't mix the control and data stacks.

~~~
titzer
Correct. In fact, WebAssembly does not allow (indirectly) addressing the data
stack at all. One must implement an addressable data stack in "userspace" with
explicit management.

------
ttd
AddressSanitizer is another approach to detect memory-related (including stack
overflow) errors in C and C++ programs. See
[https://github.com/google/sanitizers/wiki/AddressSanitizer](https://github.com/google/sanitizers/wiki/AddressSanitizer)

~~~
the_why_of_y
In contrast to the stack protector described in the linked article,
AddressSanitizer was designed as a debugging tool and is not suitable as a
mitigation mechanism for production deployments.

------
titzer
It's 2017 and we (still) have stack smashing bugs. I'm not really proud of
what this says about our field.

------
rurban
This explanation would have been fine 5 years ago, but not even mentioning the
superior -fstack-check or -fsanitize=cfi is criminal negligence.

~~~
mrich
I will write about them, too.

They are only implemented in clang. I'm using gcc for production builds so
that's what I focused on first.

