It has long been recognized that unconstrained growth of memory usage constitutes a potential denial of service vulnerability. Qualys has shown that such unconstrained growth can be combined with other vulnerabilities and exploited in ways that are more serious.
Typically, the heap and stack of a process start at opposite ends of the unused address space and grow towards each other. This maximizes the flexibility to grow the regions over the course of execution of the program without apriori knowing how much of either resource is needed or even the relationship between their needs.
Heap growth is explicit (via malloc), stack growth is implicit. Stack growth depends on the process accessing an unmapped page in memory. This write causes a segmentation fault (SEGV). The kernel catches the SEGV and either extends the stack, returning control to the application or halts the application if the stack cannot be extended.
Over a decade ago, the concept of a stack guard page was introduced to prevent the heap and stack from colliding. The guard sits at the end of the currently allocated stack. When the kernel tries to extend the stack, it will also move the guard. If the guard cannot be moved (because it would collide with the heap), then the process is terminated.
Guard page protection requires that the process access data on the guard page. That access creates a SEGV that the kernel intercepts to trigger extending the stack and checking the guard page for a collision with the heap.
--
Qualys has developed exploits by first using memory leaks, large allocas and/or other tricks to bring the stack and heap close together. Then a function with a large static or dynamic stack allocation can be used to "jump the guard". "Jumping the guard" occurs by advancing the stack pointer by more than a page without writing into the allocated area. After jumping the guard, the heap and stack have collided. The attacker can then use rites into the stack to change objects or metadata on the heap or vice-versa.
Qualys have implemented multiple proofs of concept exploits using these techniques on Linux and BSD systems. It is almost guaranteed that other systems such as Solaris and some embedded systems are also vulnerable to this attack vector.
Glibc presents the attacker with a particularly inviting target because it is mapped into every running process on a Linux system. It provides the full set of vulnerabilities necessary to mount these attacks. Our initial response is to close down the large/unbound allocations within glibc which Qualys's proof of concept exploits currently use.
However, this is just a stopgap measure and as we close down one set of vulnerabilities the attackers will just look for other vulnerable points to exploit. Thus, we have been aggressively developing a more comprehensive strategy to eliminate these problems at minimal cost.
In particular, these exploits depend on finding stack allocations, which are larger than a page and which do not immediately access those pages. Those allocations are key to "jumping the guard" and present a choke point for mitigation.
We can arrange for the compiler to "probe" the stack when making large allocations to ensure that there is an access to each page during or immediately after allocation. Thus, the stack guard page will be accessed if there is an attack in progress and the kernel will halt the process.
That's it for today. Next is a discussion of why existing probing mechanisms in GCC are generally not sufficient for protecting code from stack-clash style attacks.
Last updated: September 22, 2017