On 13/04/16 14:01, Cristina Georgiana Opriceana wrote: > 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 think it does not provide complete protection. it cannot instrument the c runtime or dsos and attacks can be retried on a forking server which has fixed memory layout, so there is still significant attack surface. (it would be nice if security experts made such claims much more carefully). > In GCC, we propose a design composed of an instrumentation module > (implemented as a GIMPLE pass) and a runtime library. ... > 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. the SafeStack runtime in compiler-rt has various issues that should be clearly documented. it seems the runtime * aborts the process on allocation failure. * deallocates the unsafe stack using tsd dtors, but signal handlers may run between dtors and the actual thread exit.. without a mapped unsafe stack. * determines the main stack with broken heuristic (since the rlimit can change at runtime i don't think this is possible to do correctly in general). * interposes pthread_create but not c11 thrd_create so conforming c11 code will crash. (same for non-standard usage of raw clone.) * sigaltstack and swapcontext are broken too. i think the runtime issues are more likely to cause problems than the compiler parts: it has to be reliable and abi stable since safestack is advertised for production use. (i think gcc should raise the bar for runtime code quality higher than that, but there is precedent for much worse runtimes in gcc so this should not block the safestack porting work, however consider these issues when communicating about it to upstream or to potential users.)
