The Stack Clash
Last updated on: December 19, 2022
Table of Contents
- What is the Stack Clash?
- What is the Stack Clash vulnerability, precisely?
- Why is it called the Stack Clash?
- Is it a new vulnerability?
- Is the Stack Clash one or several vulnerabilities?
- Am I affected by the Stack Clash?
- What are the risks posed by the Stack Clash?
- Is it exploitable remotely?
- How can I protect my system from the Stack Clash?
- What if I cant (or dont want to) update or reboot my system?
- Where can I find the Stack Clash exploits?
- Where can I get more information?
- I want to write my own Stack Clash exploit, where do I start?
- Is the Sudo vulnerability Qualys published on May 30 related to Stack Clash?
What is the Stack Clash?
The Stack Clash is a vulnerability in the memory management of several operating systems. It affects Linux, OpenBSD, NetBSD, FreeBSD and Solaris, on i386 and amd64. It can be exploited by attackers to corrupt memory and execute arbitrary code.
Qualys researchers discovered this vulnerability and developed seven exploits and seven proofs of concept for this weakness, then worked closely with vendors to develop patches. As a result we are releasing this advisory today as a coordinated effort, and patches for all distributions are available June 19, 2017. We strongly recommend that users place a high priority on patching these vulnerabilities immediately.
What is the Stack Clash vulnerability, precisely?
Each program running on a computer uses a special memory region called the stack. This memory region is special because it grows automatically when the program needs more stack memory. But if it grows too much and gets too close to another memory region, the program may confuse the stack with the other memory region. An attacker can exploit this confusion to overwrite the stack with the other memory region, or the other way around.
Why is it called the Stack Clash?
The first step in exploiting this vulnerability is to collide, or clash, the stack with another memory region. Hence the name: the Stack Clash.
Is it a new vulnerability?
The idea of clashing the stack with another memory region is not new: it was exploited a first time in 2005 and a second time in 2010. After the 2010 exploit, Linux introduced a protection against such exploits: the so-called stack guard-page. Today, we show that stack clashes are widespread and exploitable despite the stack guard-page protection.
Is the Stack Clash one or several vulnerabilities?
Our primary Stack Clash vulnerability is CVE-2017-1000364 and demonstrates that a stack guard-page of a few kilobytes is insufficient. But during our research we discovered more vulnerabilities: some are secondary and directly related to the primary Stack Clash vulnerability (for example, CVE-2017-1000365), and some are exploitable independently (for example, CVE-2017-1000367).
Am I affected by the Stack Clash?
If you are using Linux, OpenBSD, NetBSD, FreeBSD, or Solaris, on i386 or amd64, you are affected. Other operating systems and architectures may be vulnerable too, but we have not researched any of them yet: please refer to your vendor’s official statement about the Stack Clash for more information.
What are the risks posed by the Stack Clash?
The exploits and proofs of concept that we developed in the course of our research are all Local Privilege Escalations: an attacker who has any kind of access to an affected system can exploit the Stack Clash vulnerability and obtain full root privileges.
Is it exploitable remotely?
Our research has mainly focused on local exploitation: as of this writing on June 19, 2017, we do not know of any remotely exploitable application. However, remote exploitation of the Stack Clash is not excluded; although local exploitation will always be easier, and remote exploitation will be very application-specific. The one remote application that we did investigate (the Exim mail server) turned out to be unexploitable by sheer luck.
How can I protect my system from the Stack Clash?
The easiest and safest way to protect your system is to update it: we have been working with the affected vendors since the beginning of May, and by the time you read this, their patches and updates will be available.
What if I can’t (or don’t want to) update or reboot my system?
As a temporary workaround, you may set the hard RLIMIT_STACK and RLIMIT_AS of your local users and remote services to some reasonably low values. Use this workaround at your own risk, however: most likely your limits will not be low enough to resist all attacks (for example, in some cases our Sudo stack-clash exploit allocates merely 137MB of heap memory, and almost no stack memory); or your limits will be too low and will break legitimate applications.
Where can I find the Stack Clash exploits?
As of June 28, 2017, we have published the accompanying exploits.
Where can I get more information?
Please refer to the Stack Clash security advisory for the full technical details.
OR:
Refer to the vendor advisories, which we are listing here as they become available:
SUSE
https://www.novell.com/
Red Hat
https://access.redhat.com/
Debian
https://www.debian.org/
https://www.debian.org/
https://www.debian.org/
https://www.debian.org/
Ubuntu
https://www.ubuntu.com/usn/
OpenBSD
https://ftp.openbsd.org/pub/
Oracle Solaris
http://www.oracle.com/
I want to write my own Stack Clash exploit, where do I start?
You should try to implement the local-root exploit against Exim on i386 Debian: it is by far the easiest and most representative Stack Clash exploit.
Is the Sudo vulnerability Qualys published on May 30 related to Stack Clash?
https://www.qualys.com/2017/06/14/cve-2017-1000367/cve-2017-1000367.txt https://www.qualys.com/2017/06/14/cve-2017-1000367/linux_sudo_cve-2017-1000367.c
If CVE-2017-1000367 is combined with the Stack Clash, any local user (not just Sudoers) can exploit Sudo to obtain full root privileges on any vulnerable Linux system (not just SELinux systems). Because CVE-2017-1000367 was exploitable independently of the Stack Clash, we (and the affected vendors) decided to not wait for the June 19 Coordinated Release Date and published it on May 30.
Is there any info as to whether the macOS operating system kernel is affected?
Not yet, but Apple is investigating.
No doubt I have some important misunderstanding here, but why is it part of the suggested temporary workaround to set the address space limit RLIMIT_AS to a low value? Stack and heap share the same address space, else stack clash would not be possible. Does not providing a smaller address space therefore force stack and heap to be closer together (on average, subject to ASLR)? It seems like that would be counterproductive.
RLIMIT_AS does not modify the address space layout itself, it just limits the amount of memory that the process can allocate.
I think I also may be missing something, unless the main concern is 32 bit Linux kernels, since you only have only 3G of addressable memory per process. Doesn’t each process get its own MMU page map so you put stack and heap at opposite ends of process address space with so essentially “infinite” space between them in a 64 bit OS? It seems like the exploitability of this could depend on the amount of virtual memory configured combined with the free virtual space too. (On the other hand if mmap is implicated, you could essentially cause all of your virtual memory address space to fill up with references backed by the file system, independent of configured swap. I would suspect that is probably a separate, more rare exploit as most programs don’t map arbitrary sized files into their memory space and allow users to directly access them. In this theoretical exploit, you could access all of the processes’ address space randomly with a sufficiently large file, though.)
Independent of mmap, isn’t there a requirement to have enough virtual memory available to fill the space up to the minimum stack address? This should be something OS designers minimized long ago through a default OS setting of max stack to 512M or 1G on 32 bit kernels and 4 or 8G on 64 bit kernels, located at the top of the memory space, or right below the kernel address space at least… Linux has had 64bit available for so long, and the 64 bit processor so well established, it seems like most people should really take the leap and go 64 bit kernel which should make this a non issue with properly coded memory management.
It is easy to exploit 32-bit Linux because of its limited address-space, but 64-bit Linux is also exploitable: yes, the stack is mapped at the top of the address-space, but the mmap()s are mapped at a random distance below the stack, and this random distance can be as small as 128MB. Consequently, if the initial stack is 128MB or more (easy with many command-line arguments and/or environment variables) then the stack and the mmap()s can be, in fact, adjacent.
So, are you saying that mmap is the crux of most of the 64 bit kernel Stack Clash exploits or just another tricky aspect of making sure that you never give a user accidental access to the stack?
To exploit a stack-clash, some memory region has to be mapped very close to the stack. In theory, this should be impossible on 64-bit, because the address-space is so vast that it should require an insane amount of memory to map something close to the stack. In practice, however, the minimal mmap-stack distance (128MB) makes exploitation possible on Linux 64-bit.