Slashdot Mirror
'Stack Clash' Linux Flaw Enables Root Access. Patch Now (threatpost.com)
msm1267 writes: Linux, BSD, Solaris and other open source systems are vulnerable to a local privilege escalation vulnerability known as Stack Clash that allows an attacker to execute code at root. Major Linux and open source distributors made patches available Monday, and systems running Linux, OpenBSD, NetBSD, FreeBSD or Solaris on i386 or amd64 hardware should be updated soon.
The risk presented by this flaw, CVE-2017-1000364, becomes elevated especially if attackers are already present on a vulnerable system. They would now be able to chain this vulnerability with other critical issues, including the recently addressed Sudo vulnerability, and then run arbitrary code with the highest privileges, said researchers at Qualys who discovered the vulnerability.
The risk presented by this flaw, CVE-2017-1000364, becomes elevated especially if attackers are already present on a vulnerable system. They would now be able to chain this vulnerability with other critical issues, including the recently addressed Sudo vulnerability, and then run arbitrary code with the highest privileges, said researchers at Qualys who discovered the vulnerability.
Two words: "priviledge" and "escalation".
You might not be giving random people shell access to your server, but if they've managed to acquire it through some other means (e.g. a compromised acccount or some other form of compromise) this means that they can pretty much be assured of being able to go from there to root until you install the patch. Not as bad as a remote root exploit, but still very nasty and worth the "Patch Now".
UNIX? They're not even circumcised! Savages!
Very interesting that the major flavors (Sys V, BSD, and Linux [which I consider a rewrite of Sys V]) are vulnerable. Sounds like a deep seated logic flaw there. Wonder if other vendor specific ones (IRIX, SunOS, Ultrix, AIX, etc) are vulnerable.
I'm actually still wondering if any of the above except Linux actually are vulnerable.
Only the "threatpost.com" article claims so, and of course the copy/pasted slashdot summary.
But the security researchers quoted in that very article explicitly say they discovered this in Linux, and nothing else.
The CVE issued explicitly says Linux kernels from 3.0 to 4.11.5 as well, no CVEs for other kernels or OSes.
Also the vulnerability in Linux only applies to Intel x86 and amd64 architectures, and it has been proven not to work on ARM processors.
So if it is processor specific, under what basis are they even assuming it would work on IRIX (riscX000 processors) or SunOS (Sparc processors) and so on?
That isn't to say x86 versions of the other OSes aren't vulnerable, but I'd like to see at least one person on earth attempt it to find out.
Threatpost just seemed to pulled that out of their ass to make one claim that has hasn't even been tested, and a few more claims that are actually proven false, which in the end makes their first unproven claim suspect, since if they are correct at all it was only by accident.
Sifting through the CVE and the write-up:
The kernel places an unmappable guard page just below the process's maximum-alloted stack space. Normally a process gets allocated only as much stack space as it needs. When the process's stack usage grows, the kernel maps additional pages to grow the process's stack space, but will not grow it beyond the maximum alloted stack size. If the process enters an infinite recursion loop, it'll hit the end of the alloted stack space, and the unmappable guard page segfaults the process out of its misery.
The problem appears to be if the process's heap is right next to the stack, with only the guard page separating it from the stack, and a single function call creates a stack frame that exceeds the size of the guard page. This effectively places the stack pointer into the heap. The function call thinks it has allocated its usual, large stack frame, but the stack pointer is in the heap.
At this point, usual code execution will typically make further use of the stack, so it ends up crapping all over the heap.
That's not good, of course. But I would expect the process in question to attempt to access its alleged stack frame before much happens. At this point the process will try to access the guard page, and gets segfaulted. That, at least, is my understanding of the vulnerability.
The overall design involving a guard page to limit the size of the process's stack is a traditional OS design, which is why the general approach affects both Linux and BSDs, here.
For this to be remotely exploitable, the attacker has to arrange for a process to execute a function call that creates a large stack frame so that the stack pointer jumps over the guard page. I would expect common, battle-tested free software that powers the intertubes to be well designed and written by experienced greybeards who fully understand how an operating system works, and the fact that the stack is not an endless resource, that it is quite a limited resource actually; with the resulting code minimizing automatically-scoped object usage on the stack, which should eliminate the vulnerability completely.
I find Red Hat's write-up somewhat puzzling. They appeared to have taken the tack of addressing the exploit by increasing the size of the guard area to a megabyte, rather than a single page.
That seems to be somewhat inadequate to me, in the brave-new 64-bit world of ours. It seems to me that the permanent fix would be to map the stack into virtual address space that's a terabyte, or two, away from the heap and everything else. Seems to be a no-brainer solution to me, dunno why they didn't do it.
I'm comfortable with apt-get but that's just upgrading all the softwares other than the operating system. How do I actually upgrade my OS?
My usage pattern tends to be, do a clean install of linux, install all the packages I need, edit the configuration files as I need them. Then use it till I buy a new computer only upgrading the installed packages. Then I start over. I never have actually pathced my Linux or installed an "upgrade". I'm terrified it would break all my packages.
Actually "apt-get upgrade" will also get the latest kernel as well.
The only real difference is that you need to reboot into the new kernel, a step never needed for just upgrading software packages.
That's all you need to do to patch your system against this specific vulnerability.
But if by "OS" you mean "distribution version" instead of "kernel" (IE going from Debian 7 to Debian 8), you first do an "apt-get upgrade" like normal, and afterwards do an "apt-get dist-upgrade"
However you are correct that a dist-upgrade may break software packages, or specifically your custom configuration files.
The reason they call it the "stable" distribution is because any and all upgrades to software will guarantee config file compatibility.
But between two stable major versions, this is not guaranteed. /etc configs, your copy of the "old versions" config will be kept, and may be missing required new lines or have deprecated old lines that will throw an error, thus the program won't run.
The new stable version may come with a significantly newer version of some program, not just the same version as shipped with all security fixes back-ported into it.
Because of that, if you've made any significant changes to a programs
The dist-upgrade process WILL give you an opportunity to deal with it on a manual basis, but it sucks to have to do.
Your options are basically "Keep the old possibly missing things config", or "wipe away my config and install the new versions defaults", or "show me the difference and give me an editor"
As it sounds, none of those are "fun"
BUT there is good news!
If you installed Debian 7, and Debian 8 comes out, you don't need to dist-upgrade at all.
Security fixes and updates will continue to be released for 7 for some time, and you can just keep your working system as is.
So your process of waiting until you get new hardware and doing a new install from scratch is perfectly workable for quite some time after new distro versions come out.
Wonder no more, here's the actual technical description of the problem that includes attacks on non-Linux OSes: https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt.
Slashdot editors: this link should have been in the summary. It's the relevant one to technical users interested in what the attack actually is.
It's not a kernel exploit at all. It's an exploit against distributions vulnerable enough to ship suid binaries compiled without -fstack-check.
Now, there is a kernel patch to partially mitigate the effect of bugs in suid binaries, much like the kernel implements address space layout randomization to mitigate shellcode attacks, but the vulnerability exists in the application binary, not the kernel.