Stack Clash Vulnerability - Introduction

Stack clash vulnerability allows adversaries to corrupt memory and execute arbitrary code. In Linux, heap grows by way of explicit system call brk(). On the other hand when stack grows into unallocated region, it triggers a pagefault. OS then allocates the memory if that doesn't extend into the stack guard. If the stack grows into already allocated region belonging to other region such as heap, kernel would not know. Adversaries can then use this to inject and execute shell code.

Stack clash attacks are not new.  Gael[3] and Rafal[2] presented them in 2005 and 2010 respectively. This is performed by allocating large amount of mmaped pages and then performing a large recursive call such that the stack is overflown and collides with the mmaped page. After this, Linux (and other OS) provided a stack guard below the stack which is not mappable to circumvent this attack.  Thus accessing this area will trigger a page fault. Compilers such as gcc also provide static smashing protection that can detect some of the stack overflows.

Qualys researchers recently demonstrated various ways to still use them to gain access into Linux like O/S. Qualsys in their research shown that by way jump over the guard page. This involved:

• Clash the stack with large stack allocation and bring the stack pointer back to its region. One way to do this is by having a recursive call.
• Jump over the stack guard page into the other region. Qualsys [1] lists various ways to do this including using glibc's vfprintf() function.  vfprintf function allows allocation of stack buffer which is not fully written. Refer to [1] for complete detail.
• Smash in the region

gcc -fstack-check implementation aims to prevent this but unfortunately failed at it. Jeff Law from Redhat posted a seres of patches [5] to gcc to handle this. Kernel also increase the stack guard size [6]. There were also glibc patches that fixed some of the associated issues.

In the next blog I will go into the details of how gcc is modified to detect stack clash vulnerability.

Reference:

[1] https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt

[2] https://cansecwest.com/core05/memory_vulns_delalleau.pdf

[3] http://invisiblethingslab.com/resources/misc-2010/xorg-large-memory-attacks.pdf

[4] https://access.redhat.com/security/vulnerabilities/stackguard

[5] https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01112.html

[6] https://patchwork.kernel.org/patch/9796395/