Gabi Moisa - Fotolia
Qualys Inc. researchers found a privilege escalation vulnerability, which they call Stack Clash, in Unix-based OSes, including Linux and OpenBSD. Linux developers produced a fix intended to prevent stack clashes in 2010, but the researchers easily bypassed it. What is the vulnerability, and how can Unix-based OS users apply protections?
Programs running on a computer have two types of memory available: stack-based and heap-based memory. They are both stored in the computer's random access memory. The stack is responsible for keeping track of the running memory needed in an application and, as the name implies, it stacks this memory allocation on top of the first memory allocation.
The heap is used for dynamic memory allocation, and it is a heap of objects, such as files being viewed or edited. The stack is automatically expanded by the kernel when a program needs more stack memory, but the way it expands can be prone to errors, as it relies on page-fault exceptions to provision additional memory.
If the stack pointer attempts to access memory beyond the call stack's bounds and the unmapped memory pages below it -- the stack grows down -- a page-fault exception is raised and caught by the kernel. Then, the page-fault handler can transparently expand the process stack.
However, if another memory region is mapped directly below the stack, the kernel cannot tell that the process needs more stack memory, and the stack pointer can move from the stack into the other memory region without raising a page fault. This creates a situation where the stack can write to the other memory region and vice versa.
Gael Delalleau wrote about this problem in 2005, and in 2010, Rafal Wojtczuk published "Exploiting large memory management vulnerabilities in Xorg server running on Linux," tracked as CVE-2010-2240. This prompted the Linux kernel developers to mitigate the problem by using a stack guard page; the kernel places an unmappable guard page below the start of the stack that raises an exception if accessed.
Researchers at Qualys discovered that a guard page of a few kilobytes is insufficient, as the stack pointer can be made to jump over the guard page and extend into another memory region without raising a page-fault exception. This can lead to various attack scenarios resulting in arbitrary code execution and privilege escalation.
Dubbed the Stack Clash vulnerability, this affects Linux, OpenBSD, NetBSD, FreeBSD and Solaris on i386 and amd64 operating environments. Qualys fears other operating systems and architectures that they have not researched may also be vulnerable to Stack Clash -- they developed seven exploits and seven proofs of concept for clashing the stack with another memory region.
It's not yet known whether Stack Clash attacks can be carried out remotely, but even local exploitation is dangerous, as the attacker gains the privileges of the hijacked program. Also, these attacks use trusted, system-level programs such as sudo, ld.so and rsh. These programs have root privileges, so the attacker can take over the whole system as an administrator.
Qualys worked with vendors to produce advisories and patches for all distributions.
As a temporary workaround, administrators may set the hard RLIMIT_STACK and RLIMIT_AS of local users and remote services to some reasonably low values, but this may well break legitimate applications. A better option is to place a high priority on patching these vulnerabilities immediately. The primary Stack Clash vulnerability -- CVE-2017-1000364 -- and details of the other vulnerabilities discovered by Qualys are available on its website.
Ask the expert:
Want to ask Michael Cobb a question about application security? Submit your questions now via email. (All questions are anonymous.)
Dig Deeper on Alternative operating system security
Related Q&A from Michael Cobb
WhatsApp vulnerabilities can enable hackers to bypass end-to-end encryption and spoof messages. Expert Michael Cobb explains how these attacks work ... Continue Reading
Disabling Google location tracking involves more than turning off Location History. Learn how to manage your account settings to stop tracking ... Continue Reading
Compared to TLS 1.2, TLS 1.3 saw improvements in security, performance and privacy. Learn how TLS 1.3 eliminated vulnerabilities using cryptographic ... Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.