On 04/13/2016 07:01 AM, Cristina Georgiana Opriceana wrote:
Hello,
I bring to your attention SafeStack, part of a bigger research project
- CPI/CPS [1], which offers complete protection against stack-based
control flow hijacks. I am interested in developing SafeStack for GCC
and I would like to ask for your feedback on this proposal.
SafeStack is a security mechanism that protects against stack based
control flow attacks, while also keeping a low runtime overhead - it
prevents all stack-based attacks in the RIPE benchmark, and has just
0.05% overhead on average on SPEC CPU2006 benchmarks [2]. Safestack
has been recently merged into the Clang/LLVM mainline [3].
Its design is based on the separation of stack-allocated memory
objects in two regions: the safe stack, where we keep the return
addresses, spilled registers and local variables proved to be only
accessed in a safe way by a static analysis pass at compilation, and
the regular region, where we move everything else.
With this separation and randomized-based isolation of the safe stack,
we ensure that no overflows from the unsafe stack can overwrite
sensitive data from the safe stack. Further on, the isolation
mechanism can be improved to use hardware segment protection or
hardware extensions, such as Intel Memory Protection Keys.
We aim to extend all of CPI into the GNU userland, but start with a
SafeStack port in GCC.
In GCC, we propose a design composed of an instrumentation module
(implemented as a GIMPLE pass) and a runtime library.
The instrumentation pass will perform static analysis to discover
stack objects that are only accessed in a safe way. It will also
insert code that allocates a stack frame for the rest of the objects,
those that did not satisfy the safety condition. The pass will run
independently, after GIMPLE lowering, scheduled on the all_passes list
and after other optimizations, such as dead code elimination. Then,
all accesses to unsafe objects have to be re-written, based on the new
stack base and offset in the unsafe stack. In the first phase of the
implementation, the unsafe stack will be allocated on the heap, and we
will rely on ASLR for the isolation.
The runtime support will have to deal with unsafe stack allocation - a
hook in the pthread create/destroy functions to create per-thread
stack regions. This runtime support might be reused from the Clang
implementation.
This all sounds good. And I'd definitely look to re-use the runtime and
perhaps tests from Clang.
Jeff
