This is the mail archive of the
mailing list for the GCC project.
Re: SafeStack proposal in GCC
- From: Volodymyr Kuznetsov <vova dot kuznetsov at epfl dot ch>
- To: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Wed, 20 Apr 2016 18:09:54 +0200
- Subject: Re: SafeStack proposal in GCC
- Authentication-results: sourceware.org; auth=none
- References: <CAFA9rWPkb=eV0GhvFeOnd4pRVh=N3fSifYBwZjy9Ndh68BmBww at mail dot gmail dot com> <0d50f0ef01b24c25a79a6f18eaddfd6d at REXA dot intranet dot epfl dot ch>
On Wed, Apr 20, 2016 at 4:54 PM, Szabolcs Nagy <email@example.com> wrote:
> On 13/04/16 14:01, Cristina Georgiana Opriceana wrote:
>> I bring to your attention SafeStack, part of a bigger research project
>> - CPI/CPS , 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).
OK, the point is well taken, every actual implementation of such
techniques is bound to have limitations like the ones you mention. The
protection can only be complete in an academic sense: assuming the
perfect implementation that follows the CPI formal model, has perfect
safe region isolation, etc. In practice, we're just trying to make the
attacker's job harder.
>> 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
> the SafeStack runtime in compiler-rt has various issues
> that should be clearly documented.
Thanks a lot for pointing it out, getting such feedback is one of the
reasons we want to upstream this in the first place. The other reasons
include getting more people to use and to improve the code by fixing
> 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.
I think the only correct way to handle this is to put the unsafe stack
allocation/deallocation code into libc. We implemented it for FreeBSD
libc in a way that imposes no overhead for apps that don't use
safestack, perhaps something similar could be possible in glibc. We'd
welcome any better suggestions on this!
> * 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.
We have prototype that supports swapcontext that we're happy to
release, but it clearly requires more work before being ready to merge
> 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.)