Hardened/Gentoo Hardened and Stack Clash

Executive summary
With Gentoo Hardened no ebuilds compiled with a hardened toolchain with version 4.8 or higher should be affected by this issue as  is enabled by default. The only known exceptions are and (on HPPA)  wich disable this feature.

Introduction
The Gentoo Hardened team has been made aware of a set of vulnerabilities known as Stack Clash.

These vulnerabilities involve the process overflowing its stack onto other memory regions allowing the attacker to either modify the contents of the stack itself or the memory region on which the stack overflows. As a result, an attacker may be able to modify the data of affected programs or their execution flow and trigger the execution of arbitrary code.

The existence of such issues has been known since at least 2005 when Gael Delalleau presented an example of such an issue affecting mod_php in apache.

Requirements to perform the attack

 * The attacker needs to be able to make the stack pointer overflow onto an adjacent memory region without accessing the stack guard page.
 * The attacker needs to be able overwrite either the stack or the adjacent section in a meaningful way, for example overwriting the return address of a function to take control of the execution flow.

Effect of Gentoo Hardened protections
As a way to make exploitation of such issues harder vanilla Linux kernels introduced a 4kiB gap between the stack and the other regions called guard page, on PaX based kernels like hardened-sources this gap defaults at 64kiB and can be modified using. As shown by Qualys' advisory, such gap isn't large enough for all allocations and can be jumped over in some cases.

It should be noted that increasing the size of this gap will not deter all exploitation attempts as large enough allocations may still be able to jump over the gap. It will though affect the processes running on the system and limit the amount of virtual memory space available to them. Although this might not be a problem on 64 bit architectures where the virtual memory space is quite large, on 32 bit architectures this may still be problematic and should be taken into account before using a large heap_stack_gap value.

The Gentoo Hardened toolchain also makes use of 's Stack Checking feature using since  4.8. This makes add stack probing code when large allocations are made ensuring that the guard page or the stack gap are accessed. This will then prevent the attack by killing the process.

To be fully effective, requires that all the source files used by the process have been compiled making use of this feature. This is because may optimize away some of the checks that are considered redundant.

An assesment over the Gentoo Portage tree hints that only two packages disable this feature. Some ebuilds for disable the flag to address. On the other hand, some ebuilds for disables this feature on HPPA builds to address.

It is possible to check the version of the compiler used on a specific ELF binary by checking the value of the section as long as it was not stripped. For this the command can be used, for example to check  run the following command: Users of the portage feature should instead check the debug file on. For example the prior example for would be:

Prior versions of the toolchain make use of which, although not preventing the issue, will make it harder for an attacker to take control of the execution flow of the program as depending on how the attack is performed the attacker may need to find out the value of the canary in the stack.

In this case caution is advised because the amount of ebuilds disabling SSP is much larger and the attacker will be able to overwrite the return pointer if the frame of any function provided by the binaries generated using these ebuilds ends up on the overflowed into memory section.

Most of the binaries in Gentoo Hardened are also compiled as PIE binaries, this allows using ASLR which both vanilla and PaX kernels provide with the second being noticeably stronger. This will make it harder for an attacker to figure out a valid address on which to return.

Additionally PaX can prevent RWX mappings including the stack itself, this makes it more difficult for the attacker to introduce new code forcing him to use executable code already present on the process at the time of the attack. Keep in mind though that most programs making use of JIT compilers will have this feature disabled.

Finally, allows enabling Deter exploit bruteforcing. This feature limits the number of unsuccessful attack attempts that can be made against SUID binaries making exploitation noticeably harder.

Conclusion
With the exception of exploits able to make use of to jump over the thread gap or (on HPPA systems)  users of Gentoo Hardened who have recompiled their userspaces using  4.8 or higher are protected against stack overflow issues.

Users of prior versions of have also partial protection against some of the exploits thanks to PIE and SSP although they should reconsider rebuilding their userspace with a more modern version of the hardened toolchain.

Further reading reading and sources

 * Advisory by Qualys
 * Jeff Law on -fstack-check needing full coverage to be effective
 * Grsecurity's project comments on the issue
 * GCC's Stack Checking
 * GCC's Stack Checking

Thanks
The Gentoo Hardened team would like to thank the PaX Team for its outstanding work and its support whilst writting this statement.

We'd also like to thank Zorry for his hard work introducing on the toolchain.

The latest version of this statement can be found on