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?
SnapOverflow
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:
Quoting the LWN article about the original fix from 2010:
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:
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)'):Sudo
The aforementioned sudo bug is covered by USN-3304-1, from May 30, 2017:
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.