There are a number of exploit mitigation techniques to reduce the impact of common C vulnerabilities. Unfortunately they are not as widely used as they should in free operating systems.

For ASLR to work properly Linux needs position independent code and position independent executables (CFLAGS -fpic and -pie). Currently most Linux distributions don't enable pie by default.

• Many file managers (Nautlius, Dolphin) won't execute position independent executables. The root cause of this is that technically there is no clear distinction between executables and libraries and libmagic will detect all position independent executableas as mime type “x-sharedlib”. This issue is currently being tracked in the file/libmagic bugtracker.
• There is a small performance impact of around 1-2 % when using position independent executables on 64 bit. The impact is higher on 32 bit x86.
• Copy relocation support in gcc and binutils should reduce the performance impact on x86_64, requires changes to binutils/gcc, is being worked upon upstream and will likely be part of next releases. oss-security discussion, gcc part, binutils part
• Ubuntu Wiki page with PIE notes
• GCC patch to add configure switch allowing PIE by default

The grsecurity project includes many exploit mitigation techniques. It is a patch for the Linux kernel. Based on experience many local root exploits in the past were prevented on systems using grsecurity.

Most likely many parts of grsecurity could be integrated into the mainline kernel. This would involve splitting the patchset up into single patches that change single bits and submit them to the responsible upstream subsystem maintainer.

This has already partly happened in the past, however until now only a very small subset of grsecurity improvements went upstream.

Approaches that try to implement memory safety in C:

• Control Flow Integrity and Safe Stack for clang/llvm, plans for Chrome deployment
• Levee - tries to protect only memory containing code pointers (stack return adresses, function pointer variables), relatively small overhead, LLVM-based (Code Pointer Integrity 31C3 talk).
• Address Sanitizer - mostly advertised as a debugging / fuzzing tool, could in theory also be used for production software, significant overhead, part of both LLVM and GCC in current versions (compiler flag -fsanitize=address).
• Softbound+CETS - very strong memory protection, large overhead (over 100%), not in a state that it works with large real-world software, LLVM-based (Bug class genocide 30C3 talk)

• checksec.sh - shell script testing executables for common exploit mitigation techniques