28

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?
Faheem Mitha
  • 7,831
muru
  • 197,895
  • 55
  • 485
  • 740

2 Answers2

30

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:

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
muru
  • 197,895
  • 55
  • 485
  • 740
  • So in summary it should already be fixed in most Ubuntu versions that are still supported, one just need to update? – CJCombrink Jun 20 '17 at 06:40
  • @TheBadger no, as noted by the CVE tracker, some combinations are still listed as release pending. I suppose more USNs will be published as fixes are released. – muru Jun 20 '17 at 06:42
  • 4
    But, yes, updating should be enough, additional configuration isn't needed. – muru Jun 20 '17 at 06:48
  • If it is affecting, how to verify? – d a i s y Jun 20 '17 at 08:18
  • @daisy unless you're on a patched kernel, you are affected. The example exploit uses a now-patched bug in sudo, but the technique is general enough that other vectors could be used. – muru Jun 20 '17 at 08:33
  • Hang on, you're telling me Linux binaries don't use stack probing? WTF? – user253751 Jun 21 '17 at 06:42
  • 1
    @immibis according to following article they are, but existing implementation doesn't work correctly: Stackguard bug explanation by Qualys Research Labs – Igor B Jun 23 '17 at 10:36
  • @IgorB That's a stack guard page. Stack probing is where a function that allocates lots of stack space will deliberately access the guard page, whichs eliminates the possibility of "jumping over it". It's standard on Windows since forever, as far as I'm aware. – user253751 Jun 25 '17 at 03:38
1

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.

user7761803
  • 117