What is Stack Clash and what can I do about it?

Question

I have heard about a new vulnerability named Stack Clash which apparently affects multiple Unix-like systems (not just Linux, but the BSDs, Solaris as well).

• What is it? How did a multi-OS bug come to happen?
• How do I protect my systems?

Answer 1

Stack Clash is an exploit based on a fairly old technique. The memory used by a process is divided into two regions - the stack and the heap. One generally imagines the stack as growing downwards and the heap as growing upwards. What happens when the either grows enough to clash with the other? More generally, what happens when the stack grows enough to encroach into unrelated memory spaces? The original vulnerability is 12 years old, and the Linux kernel developers fixed it temporarily by using a guard page. However, researchers at Qualys have managed to exploit this despite the guard page.

Ars Technica reports:

Stack Clash vulnerabilities have slowly gained widespread awareness, first in 2005 with the findings of security researcher Gaël Delalleau and five years later with the release of a Linux vulnerability by researcher Rafal Wojtczuk. Linux developers introduced a protection that was intended to prevent stack clashes, but today's research demonstrates that it's relatively easy for attackers to bypass that measure.

The primary proof-of-concept attack developed by Qualys exploits a vulnerability indexed as CVE-2017-1000364. Qualys researchers also developed attacks that use Stack Clash to exploit separate vulnerabilities, including CVE-2017-1000365 and CVE-2017-1000367. For example, when combined with CVE-2017-1000367, a recently fixed flaw in Sudo also discovered by Qualys, local users can exploit Sudo to obtain full root privileges on a much wider range of OSes. Qualys has so far been unable to make the exploits remotely execute code. The sole remote application they investigated was the Exim mail server, which coincidentally turned out to be unexploitable. Qualys said it can't rule out the possibility that such remote code-execution exploits exist. Qualys said it will release the proof-of-concept exploits at a later date, once people have had time to protect against the vulnerabilities.

[...] Much more information is available in this detailed technical advisory from Qualys and this technical analysis from grsecurity.

Quoting the LWN article about the original fix from 2010:

Because Linux does not separate process stack and heap pages, overrunning a stack page into an adjacent heap page is possible. That means that a sufficiently deep stack (from a recursive call for example) could end up using memory in the heap. A program that can write to that heap page (e.g. an X client) could then manipulate the return address of one of the calls to jump to a place of its choosing. That means that the client can cause the server to run code of its choosing—arbitrary code execution—which can be leveraged to gain root privileges.

The above description applies to various Unix-like kernels.

While Ars Technica does note a temporary workaround mentioned in the Qualys report ("set the hard RLIMIT STACK and RLIMIT_AS of local users and remote services to a low value"), it should be noted that this doesn't necessarily safeguard against this exploit. The only safe way out currently is to upgrade. According to the grsecurity analysis:

It should be clear that kernel-only attempts to solve this problem will necessarily always be incomplete, as the real issue lies in the lack of stack probing. Since the alternative real solution depends on rebuilding all userland, this is likely the only feasible solution for the foreseeable future.

The best we can do now is upgrade the kernel to a patched version.

The 2010 exploit used the X server, this one used sudo, the next one could be any of a multitude of userland programs that, at some point, run under elevated privileges.

Qualys has not published any proof-of-concept code for exploits as yet (they plan to do so at a later date).

---

There are multiple Ubuntu Security Notices associated with CVE-2017-1000364:

• USN-3324-1 (Updated)
• USN-3325-1 - Raspberry Pi 2 (Updated)
• USN-3326-1
• USN-3327-1 - Raspberry Pi 2
• USN-3328-1
• USN-3329-1
• USN-3330-1 - Qualcomm Snapdragon
• USN-3331-1 - AWS
• USN-3332-1 - Raspberry Pi 2
• USN-3333-1 - HWE
• USN-3334-1 - Xenial HWE
• USN-3335-1
• USN-3335-2 - 12.04 ESM
• USN-3338-1 - 12.04 ESM

Also note that the CVE tracker lists several release/kernel combinations as pending fixes.

Generally, the simplest fix is to update your systems to the latest kernel package ASAP.

The relevant kernel versions from the USNs (culled using for i in {24..35}; curl -s https://www.ubuntu.com/usn/usn-33$i-1/ | pup 'dl:nth-last-of-type(1)'):

Ubuntu 17.04:

linux-image-4.10.0-24-lowlatency 4.10.0-24.28

linux-image-generic-lpae 4.10.0.24.26

linux-image-generic 4.10.0.24.26

linux-image-4.10.0-24-generic-lpae 4.10.0-24.28

linux-image-4.10.0-24-generic 4.10.0-24.28

linux-image-lowlatency 4.10.0.24.26

Ubuntu 17.04:

linux-image-4.10.0-1008-raspi2 4.10.0-1008.11

linux-image-raspi2 4.10.0.1008.10

Ubuntu 16.10:

linux-image-powerpc-smp 4.8.0.56.69

linux-image-powerpc-e500mc 4.8.0.56.69

linux-image-4.8.0-56-powerpc-smp 4.8.0-56.61

linux-image-4.8.0-56-powerpc-e500mc 4.8.0-56.61

linux-image-4.8.0-56-lowlatency 4.8.0-56.61

linux-image-generic 4.8.0.56.69

linux-image-4.8.0-56-generic 4.8.0-56.61

linux-image-powerpc64-emb 4.8.0.56.69

linux-image-virtual 4.8.0.56.69

linux-image-powerpc64-smp 4.8.0.56.69

linux-image-4.8.0-56-generic-lpae 4.8.0-56.61

linux-image-generic-lpae 4.8.0.56.69

linux-image-lowlatency 4.8.0.56.69

linux-image-4.8.0-56-powerpc64-emb 4.8.0-56.61

Ubuntu 16.10:

linux-image-4.8.0-1040-raspi2 4.8.0-1040.44

linux-image-raspi2 4.8.0.1040.44

Ubuntu 16.04 LTS:

linux-image-powerpc64-smp-lts-utopic 4.4.0.81.87

linux-image-generic-lts-wily 4.4.0.81.87

linux-image-generic-lts-utopic 4.4.0.81.87

linux-image-4.4.0-81-generic-lpae 4.4.0-81.104

linux-image-powerpc64-emb-lts-vivid 4.4.0.81.87

linux-image-powerpc-e500mc 4.4.0.81.87

linux-image-generic-lpae-lts-xenial 4.4.0.81.87

linux-image-generic-lpae-lts-utopic 4.4.0.81.87

linux-image-powerpc-e500mc-lts-xenial 4.4.0.81.87

linux-image-4.4.0-81-powerpc64-emb 4.4.0-81.104

linux-image-powerpc-e500mc-lts-wily 4.4.0.81.87

linux-image-4.4.0-81-powerpc-e500mc 4.4.0-81.104

linux-image-generic-lpae-lts-wily 4.4.0.81.87

linux-image-virtual-lts-vivid 4.4.0.81.87

linux-image-virtual-lts-utopic 4.4.0.81.87

linux-image-virtual 4.4.0.81.87

linux-image-powerpc64-emb-lts-wily 4.4.0.81.87

linux-image-lowlatency-lts-vivid 4.4.0.81.87

linux-image-powerpc-e500mc-lts-vivid 4.4.0.81.87

linux-image-powerpc64-emb 4.4.0.81.87

linux-image-powerpc-smp-lts-xenial 4.4.0.81.87

linux-image-4.4.0-81-generic 4.4.0-81.104

linux-image-powerpc64-smp-lts-vivid 4.4.0.81.87

linux-image-lowlatency-lts-wily 4.4.0.81.87

linux-image-4.4.0-81-lowlatency 4.4.0-81.104

linux-image-generic 4.4.0.81.87

linux-image-lowlatency-lts-xenial 4.4.0.81.87

linux-image-powerpc64-smp-lts-xenial 4.4.0.81.87

linux-image-powerpc64-emb-lts-utopic 4.4.0.81.87

linux-image-generic-lts-xenial 4.4.0.81.87

linux-image-generic-lts-vivid 4.4.0.81.87

linux-image-powerpc-e500mc-lts-utopic 4.4.0.81.87

linux-image-powerpc-smp 4.4.0.81.87

linux-image-4.4.0-81-powerpc-smp 4.4.0-81.104

linux-image-generic-lpae-lts-vivid 4.4.0.81.87

linux-image-generic-lpae 4.4.0.81.87

linux-image-powerpc64-smp-lts-wily 4.4.0.81.87

linux-image-powerpc64-emb-lts-xenial 4.4.0.81.87

linux-image-powerpc-smp-lts-wily 4.4.0.81.87

linux-image-virtual-lts-wily 4.4.0.81.87

linux-image-powerpc64-smp 4.4.0.81.87

linux-image-4.4.0-81-powerpc64-smp 4.4.0-81.104

linux-image-powerpc-smp-lts-utopic 4.4.0.81.87

linux-image-powerpc-smp-lts-vivid 4.4.0.81.87

linux-image-lowlatency 4.4.0.81.87

linux-image-virtual-lts-xenial 4.4.0.81.87

linux-image-lowlatency-lts-utopic 4.4.0.81.87

Ubuntu 16.04 LTS:

linux-image-4.4.0-1016-gke 4.4.0-1016.16

Ubuntu 16.04 LTS:

linux-image-snapdragon 4.4.0.1061.54

linux-image-4.4.0-1061-snapdragon 4.4.0-1061.66

Ubuntu 16.04 LTS:

linux-image-4.4.0-1020-aws 4.4.0-1020.29

Ubuntu 16.04 LTS:

linux-image-raspi2 4.4.0.1059.60

linux-image-4.4.0-1059-raspi2 4.4.0-1059.67

Ubuntu 16.04 LTS:

linux-image-4.8.0-56-powerpc-smp 4.8.0-56.61~16.04.1

linux-image-4.8.0-56-powerpc-e500mc 4.8.0-56.61~16.04.1

linux-image-4.8.0-56-lowlatency 4.8.0-56.61~16.04.1

linux-image-4.8.0-56-generic 4.8.0-56.61~16.04.1

linux-image-generic-hwe-16.04 4.8.0.56.27

linux-image-lowlatency-hwe-16.04 4.8.0.56.27

linux-image-4.8.0-56-generic-lpae 4.8.0-56.61~16.04.1

linux-image-virtual-hwe-16.04 4.8.0.56.27

linux-image-generic-lpae-hwe-16.04 4.8.0.56.27

linux-image-4.8.0-56-powerpc64-emb 4.8.0-56.61~16.04.1

Ubuntu 14.04 LTS:

linux-image-powerpc-smp-lts-xenial 4.4.0.81.66

linux-image-lowlatency-lts-xenial 4.4.0.81.66

linux-image-4.4.0-81-powerpc-smp 4.4.0-81.104~14.04.1

linux-image-4.4.0-81-powerpc-e500mc 4.4.0-81.104~14.04.1

linux-image-4.4.0-81-lowlatency 4.4.0-81.104~14.04.1

linux-image-4.4.0-81-generic-lpae 4.4.0-81.104~14.04.1

linux-image-generic-lpae-lts-xenial 4.4.0.81.66

linux-image-powerpc64-smp-lts-xenial 4.4.0.81.66

linux-image-4.4.0-81-generic 4.4.0-81.104~14.04.1

linux-image-4.4.0-81-powerpc64-smp 4.4.0-81.104~14.04.1

linux-image-generic-lts-xenial 4.4.0.81.66

linux-image-powerpc64-emb-lts-xenial 4.4.0.81.66

linux-image-powerpc-e500mc-lts-xenial 4.4.0.81.66

linux-image-virtual-lts-xenial 4.4.0.81.66

linux-image-4.4.0-81-powerpc64-emb 4.4.0-81.104~14.04.1

Ubuntu 14.04 LTS:

linux-image-powerpc-e500mc 3.13.0.121.131

linux-image-lowlatency-pae 3.13.0.121.131

linux-image-3.13.0-121-powerpc64-emb 3.13.0-121.170

linux-image-generic-pae 3.13.0.121.131

linux-image-3.13.0-121-powerpc-smp 3.13.0-121.170

linux-image-3.13.0-121-powerpc-e500mc 3.13.0-121.170

linux-image-3.13.0-121-powerpc-e500 3.13.0-121.170

linux-image-3.13.0-121-generic-lpae 3.13.0-121.170

linux-image-generic-lts-quantal 3.13.0.121.131

linux-image-virtual 3.13.0.121.131

linux-image-powerpc-e500 3.13.0.121.131

linux-image-generic-lts-trusty 3.13.0.121.131

linux-image-3.13.0-121-generic 3.13.0-121.170

linux-image-omap 3.13.0.121.131

linux-image-powerpc64-emb 3.13.0.121.131

linux-image-3.13.0-121-powerpc64-smp 3.13.0-121.170

linux-image-generic 3.13.0.121.131

linux-image-highbank 3.13.0.121.131

linux-image-generic-lts-saucy 3.13.0.121.131

linux-image-powerpc-smp 3.13.0.121.131

linux-image-3.13.0-121-lowlatency 3.13.0-121.170

linux-image-generic-lpae-lts-saucy 3.13.0.121.131

linux-image-generic-lts-raring 3.13.0.121.131

linux-image-powerpc64-smp 3.13.0.121.131

linux-image-generic-lpae-lts-trusty 3.13.0.121.131

linux-image-generic-lpae 3.13.0.121.131

linux-image-lowlatency 3.13.0.121.131

Ubuntu 12.04 ESM:

linux-image-powerpc-smp 3.2.0.128.142

linux-image-3.2.0-128-virtual 3.2.0-128.173

linux-image-3.2.0-128-generic-pae 3.2.0-128.173

linux-image-generic 3.2.0.128.142

linux-image-generic-pae 3.2.0.128.142

linux-image-highbank 3.2.0.128.142

linux-image-3.2.0-128-highbank 3.2.0-128.173

linux-image-3.2.0-128-powerpc-smp 3.2.0-128.173

linux-image-virtual 3.2.0.128.142

linux-image-powerpc64-smp 3.2.0.128.142

linux-image-3.2.0-128-omap 3.2.0-128.173

linux-image-3.2.0-128-powerpc64-smp 3.2.0-128.173

linux-image-omap 3.2.0.128.142

linux-image-3.2.0-128-generic 3.2.0-128.173

Ubuntu 12.04 LTS:

linux-image-3.13.0-121-generic 3.13.0-121.170~precise1

linux-image-generic-lpae-lts-trusty 3.13.0.121.112

linux-image-generic-lts-trusty 3.13.0.121.112

linux-image-3.13.0-121-generic-lpae 3.13.0-121.170~precise1

---

Sudo

The aforementioned sudo bug is covered by USN-3304-1, from May 30, 2017:

Ubuntu 17.04:

sudo-ldap 1.8.19p1-1ubuntu1.1

sudo 1.8.19p1-1ubuntu1.1

Ubuntu 16.10:

sudo-ldap 1.8.16-0ubuntu3.2

sudo 1.8.16-0ubuntu3.2

Ubuntu 16.04 LTS:

sudo-ldap 1.8.16-0ubuntu1.4

sudo 1.8.16-0ubuntu1.4

Ubuntu 14.04 LTS:

sudo-ldap 1.8.9p5-1ubuntu1.4

sudo 1.8.9p5-1ubuntu1.4

Answer 2

How did a multi-OS bug come to happen?

To address this part of your question specifically:

This issue arises because of the use of a shared address space for heap (which grows upwards) and stack (which grows downwards).

This design is common across many systems, hence why many systems are vulnerable to the same class of vulnerability.