| ========= |
| SafeStack |
| ========= |
| |
| .. contents:: |
| :local: |
| |
| Introduction |
| ============ |
| |
| SafeStack is an instrumentation pass that protects programs against attacks |
| based on stack buffer overflows, without introducing any measurable performance |
| overhead. It works by separating the program stack into two distinct regions: |
| the safe stack and the unsafe stack. The safe stack stores return addresses, |
| register spills, and local variables that are always accessed in a safe way, |
| while the unsafe stack stores everything else. This separation ensures that |
| buffer overflows on the unsafe stack cannot be used to overwrite anything |
| on the safe stack. |
| |
| SafeStack is a part of the `Code-Pointer Integrity (CPI) Project |
| <http://dslab.epfl.ch/proj/cpi/>`_. |
| |
| Performance |
| ----------- |
| |
| The performance overhead of the SafeStack instrumentation is less than 0.1% on |
| average across a variety of benchmarks (see the `Code-Pointer Integrity |
| <http://dslab.epfl.ch/pubs/cpi.pdf>`__ paper for details). This is mainly |
| because most small functions do not have any variables that require the unsafe |
| stack and, hence, do not need unsafe stack frames to be created. The cost of |
| creating unsafe stack frames for large functions is amortized by the cost of |
| executing the function. |
| |
| In some cases, SafeStack actually improves the performance. Objects that end up |
| being moved to the unsafe stack are usually large arrays or variables that are |
| used through multiple stack frames. Moving such objects away from the safe |
| stack increases the locality of frequently accessed values on the stack, such |
| as register spills, return addresses, and small local variables. |
| |
| Compatibility |
| ------------- |
| |
| Most programs, static libraries, or individual files can be compiled |
| with SafeStack as is. SafeStack requires basic runtime support, which, on most |
| platforms, is implemented as a compiler-rt library that is automatically linked |
| in when the program is compiled with SafeStack. |
| |
| Linking a DSO with SafeStack is not currently supported. |
| |
| Known compatibility limitations |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| Certain code that relies on low-level stack manipulations requires adaption to |
| work with SafeStack. One example is mark-and-sweep garbage collection |
| implementations for C/C++ (e.g., Oilpan in chromium/blink), which must be |
| changed to look for the live pointers on both safe and unsafe stacks. |
| |
| SafeStack supports linking statically modules that are compiled with and |
| without SafeStack. An executable compiled with SafeStack can load dynamic |
| libraries that are not compiled with SafeStack. At the moment, compiling |
| dynamic libraries with SafeStack is not supported. |
| |
| Signal handlers that use ``sigaltstack()`` must not use the unsafe stack (see |
| ``__attribute__((no_sanitize("safe-stack")))`` below). |
| |
| Programs that use APIs from ``ucontext.h`` are not supported yet. |
| |
| Security |
| -------- |
| |
| SafeStack protects return addresses, spilled registers and local variables that |
| are always accessed in a safe way by separating them in a dedicated safe stack |
| region. The safe stack is automatically protected against stack-based buffer |
| overflows, since it is disjoint from the unsafe stack in memory, and it itself |
| is always accessed in a safe way. In the current implementation, the safe stack |
| is protected against arbitrary memory write vulnerabilities though |
| randomization and information hiding: the safe stack is allocated at a random |
| address and the instrumentation ensures that no pointers to the safe stack are |
| ever stored outside of the safe stack itself (see limitations below). |
| |
| Known security limitations |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| A complete protection against control-flow hijack attacks requires combining |
| SafeStack with another mechanism that enforces the integrity of code pointers |
| that are stored on the heap or the unsafe stack, such as `CPI |
| <http://dslab.epfl.ch/proj/cpi/>`_, or a forward-edge control flow integrity |
| mechanism that enforces correct calling conventions at indirect call sites, |
| such as `IFCC <http://research.google.com/pubs/archive/42808.pdf>`_ with arity |
| checks. Clang has control-flow integrity protection scheme for :doc:`C++ virtual |
| calls <ControlFlowIntegrity>`, but not non-virtual indirect calls. With |
| SafeStack alone, an attacker can overwrite a function pointer on the heap or |
| the unsafe stack and cause a program to call arbitrary location, which in turn |
| might enable stack pivoting and return-oriented programming. |
| |
| In its current implementation, SafeStack provides precise protection against |
| stack-based buffer overflows, but protection against arbitrary memory write |
| vulnerabilities is probabilistic and relies on randomization and information |
| hiding. The randomization is currently based on system-enforced ASLR and shares |
| its known security limitations. The safe stack pointer hiding is not perfect |
| yet either: system library functions such as ``swapcontext``, exception |
| handling mechanisms, intrinsics such as ``__builtin_frame_address``, or |
| low-level bugs in runtime support could leak the safe stack pointer. In the |
| future, such leaks could be detected by static or dynamic analysis tools and |
| prevented by adjusting such functions to either encrypt the stack pointer when |
| storing it in the heap (as already done e.g., by ``setjmp``/``longjmp`` |
| implementation in glibc), or store it in a safe region instead. |
| |
| The `CPI paper <http://dslab.epfl.ch/pubs/cpi.pdf>`_ describes two alternative, |
| stronger safe stack protection mechanisms, that rely on software fault |
| isolation, or hardware segmentation (as available on x86-32 and some x86-64 |
| CPUs). |
| |
| At the moment, SafeStack assumes that the compiler's implementation is correct. |
| This has not been verified except through manual code inspection, and could |
| always regress in the future. It's therefore desirable to have a separate |
| static or dynamic binary verification tool that would check the correctness of |
| the SafeStack instrumentation in final binaries. |
| |
| Usage |
| ===== |
| |
| To enable SafeStack, just pass ``-fsanitize=safe-stack`` flag to both compile |
| and link command lines. |
| |
| Supported Platforms |
| ------------------- |
| |
| SafeStack was tested on Linux, FreeBSD and MacOSX. |
| |
| Low-level API |
| ------------- |
| |
| ``__has_feature(safe_stack)`` |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| In some rare cases one may need to execute different code depending on |
| whether SafeStack is enabled. The macro ``__has_feature(safe_stack)`` can |
| be used for this purpose. |
| |
| .. code-block:: c |
| |
| #if __has_feature(safe_stack) |
| // code that builds only under SafeStack |
| #endif |
| |
| ``__attribute__((no_sanitize("safe-stack")))`` |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| Use ``__attribute__((no_sanitize("safe-stack")))`` on a function declaration |
| to specify that the safe stack instrumentation should not be applied to that |
| function, even if enabled globally (see ``-fsanitize=safe-stack`` flag). This |
| attribute may be required for functions that make assumptions about the |
| exact layout of their stack frames. |
| |
| All local variables in functions with this attribute will be stored on the safe |
| stack. The safe stack remains unprotected against memory errors when accessing |
| these variables, so extra care must be taken to manually ensure that all such |
| accesses are safe. Furthermore, the addresses of such local variables should |
| never be stored on the heap, as it would leak the location of the SafeStack. |
| |
| ``__builtin___get_unsafe_stack_ptr()`` |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| This builtin function returns current unsafe stack pointer of the current |
| thread. |
| |
| ``__builtin___get_unsafe_stack_start()`` |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| This builtin function returns a pointer to the start of the unsafe stack of the |
| current thread. |
| |
| Design |
| ====== |
| |
| Please refer to the `Code-Pointer Integrity <http://dslab.epfl.ch/proj/cpi/>`__ |
| project page for more information about the design of the SafeStack and its |
| related technologies. |
| |
| Publications |
| ------------ |
| |
| `Code-Pointer Integrity <http://dslab.epfl.ch/pubs/cpi.pdf>`__. |
| Volodymyr Kuznetsov, Laszlo Szekeres, Mathias Payer, George Candea, R. Sekar, Dawn Song. |
| USENIX Symposium on Operating Systems Design and Implementation |
| (`OSDI <https://www.usenix.org/conference/osdi14>`_), Broomfield, CO, October 2014 |