Powerful programs run daily by users of Linux and other flavors of Unix are riddled with holes that can be exploited by logged-in miscreants to gain root privileges, researchers at Qualys have warned.
Essentially, it's possible to pull off a "Stack Clash" attack in various tools and applications to hijack the whole system, a situation that should have been prevented long ago.
It's pretty simple: an application's stack – used to hold short-term data in memory – grows down into another memory area known as the heap – which is used to hold chunks of information, such as files being viewed or edited, and so on. If you can control what's in the heap, by feeding carefully crafted data to the program, you can end up overwriting parts of the stack and hijack the flow of execution within the application. Alternatively, you can extend the stack down into the heap, and tamper with important data structures.
When that happens, and if the program has root privileges, an attacker can commandeer the trusted app to take over the whole system as an administrator. These security shortcomings were picked up last month by Qualys, which held off warning of the flaws until patches were in the works.
[Update follows. --martyb]
The Qualys Blog contains some more details:
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.
[...] 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).
[...] 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.
For full details, see the Qualys Security Advisory.
(Score: 2, Interesting) by Anonymous Coward on Wednesday June 21 2017, @01:41AM (8 children)
I was confused why this was worded so controversially, then saw the source. Stack overflows have been around for a while and aren't anything new. This is why any good production environment involves some form of process encapsulation (VM, container, chroot jail, etc). The fact that a bug in a single tool affects multiple distros shouldn't be surprising as it's the same upstream source. Keep a good update schedule and move along people. Nothing to see here.
(Score: 5, Funny) by driverless on Wednesday June 21 2017, @02:51AM (2 children)
I was confused about how it was worded, period:
Colourless Green Ideas Sleep Furiously. Cwm Fjord-bank Glyphs Vext Quiz. Hold the newsreader's nose squarely, waiter, or friendly milk will countermand my trousers. Noun Noun Noun Verb Adjective Noun Noun. lupDujHomwIj luteb gharghmey!
(Score: 2) by wirelessduck on Wednesday June 21 2017, @01:22PM (1 child)
Holy Smoking Stack Clash Batman!
What's next? A can of Stack Clash repellent bat spray?
(Score: 0) by Anonymous Coward on Wednesday June 21 2017, @05:42PM
I don't start my IDE without it. I keep it next to the bat shark repellent spray. Always best to be safe.
(Score: 2) by davester666 on Wednesday June 21 2017, @05:13AM (2 children)
Why is this not already prevented for all processes by the OS? Something like, say, a predetermined maximum stack size, then a short bit of unallocated VM (even a couple Mb) just at the end of it. Stack overflows, boom, process is done. Stack/heap collisions are ALWAYS a failure.
Hell, you could even have a non-predetermined stack size, just have the VM system notice when the process tries to allocate memory (either in the heap or the stack) right next to the other one (stack or heap respectively) and kill the process.
(Score: 0) by Anonymous Coward on Wednesday June 21 2017, @07:34AM
Artificially limiting the sack size will be a problem for stack-heavy programs. Artificially limiting the heap size will be a problem for heap-heavy programs.
But as far as I know, the OS doesn't allocate pages until they are needed, so in theory all that's needed is for the OS to keep track of how many pages it has allocated on each side, and when there is only one unallocated page left between the stack and the heap, simply refuse to allocate it.
Btw, Linux already has a default very low stack "soft ulimit", which I ran into a couple of days ago with a heavily recursive program.
(Score: 5, Informative) by TheRaven on Wednesday June 21 2017, @08:31AM
This 'new' exploit is simply realising that, though small overflows are caught by the guard page (a page or two at the end of the stack mapped as no-access, so any read or write will trap - this seems to be what you're proposing, and pretty much all operating systems have done it for a couple of decades at least), some programs can be convinced to allocate very large on-stack objects by the user and, because they'll start accessing these at the beginning (i.e. the lowest memory address, the furthest from the stack, which grows downwards), then you can overwrite arbitrary memory locations.
This is only a local root exploit if you have a setuid binary that allocates objects on the stack and allows an attacker to control their size. This has been known for a long time to be a terrible idea. Most C code doesn't use VLAs, so is immune and the few places that they do are easy to audit. C++ standard library containers all allocate on the heap, so are immune, and things like the LLVM SmallVector class only allocate a fixed amount on the stack before failing over to using heap storage and so are also immune.
sudo mod me up
(Score: 1) by Deeo Kain on Wednesday June 21 2017, @01:16PM (1 child)
Doesn't this not-so-new Linux kernel feature protect from this bug?
CONFIG_CC_STACKPROTECTOR_STRONG:
Functions will have the stack-protector canary logic added in any
of the following conditions:
- local variable's address used as part of the right hand side of an
assignment or function argument
- local variable is an array (or union containing an array),
regardless of array type or length
- uses register local variables
This feature requires gcc version 4.9 or above, or a distribution
gcc with the feature backported ("-fstack-protector-strong").
On an x86 "defconfig" build, this feature adds canary checks to
about 20% of all kernel functions, which increases the kernel code
size by about 2%.
(Score: 2) by Wootery on Thursday June 22 2017, @03:09PM
Here [lwn.net] is a good article on GCC's -fstack-protector and co.
Is the flag used by real distros though?
(Score: 2, Funny) by Anonymous Coward on Wednesday June 21 2017, @02:17AM (1 child)
Does that mean the carpet doesn't match the drapes?
(Score: 2) by driverless on Wednesday June 21 2017, @02:53AM
It's a reference to the unreleased album they were working on after London Calling. Artistic differences over naming it "Stack" was one of the reasons why Headon left shortly afterwards.
(Score: 2) by DutchUncle on Wednesday June 21 2017, @02:24AM (6 children)
One should certainly be able to allocate the stack, heap, and data in discontinuous virtual spaces and ensure that they are in separate memory management areas.
(Score: 0) by Anonymous Coward on Wednesday June 21 2017, @03:54AM (1 child)
Nope, that's just going to triple the number of page faults.
Inb4 asked to rewrite everything in some magical functional programming language that no one uses outside of academia.
(Score: 2) by Wootery on Thursday June 22 2017, @11:52AM
But safe type systems cure all ills! Haskell is a programmer's paradise... right?
In defence of the academics: research OSs written in high-level languages, such as Cosmos [wikipedia.org], presumably are immune from this sort of thing 'by nature'.
(Score: 2) by andersjm on Wednesday June 21 2017, @06:04AM (3 children)
One does. But the guard pages that ensure separation are usually just that - one single page, 4K I think. And that can be leaped over by convincing a privileged process to make a stack allocation (alloca) that is larger than the guard page size.
(Score: 2) by Dr Spin on Wednesday June 21 2017, @02:29PM (1 child)
I thought going beyond the guard page produces a page fault?
Or am I mistaken in believing that most modern operating systems are as advanced
as VMS was in 1983?
Warning: Opening your mouth may invalidate your brain!
(Score: 2) by andersjm on Wednesday June 21 2017, @06:24PM
Not if there just happens to be some accessible memory at the address next after. The MMU doesn't distinguish between stack memory and other memory, only between memory you have and don't have access to, so if your stack pointer is made to point to a valid heap address on the other side of the guard page, you won't get a page fault.
(Score: 2) by DutchUncle on Wednesday June 21 2017, @06:16PM
MMU range limits don't care about how far above/below you are. It's sort of picky that way. At least, that's what I remember since the IBM 360/67 and the PDP DECsystem-10.
(Score: 1, Informative) by Anonymous Coward on Wednesday June 21 2017, @04:03AM (3 children)
It's not "stack clash overflow", it's heap overflow, well-known and addressed problem:
https://en.wikipedia.org/wiki/Heap_overflow [wikipedia.org]
(Score: 4, Insightful) by aristarchus on Wednesday June 21 2017, @05:03AM (2 children)
So, from Microsoft covert research division? I know I often have a slack cash overflow problem.
(Score: 5, Funny) by davester666 on Wednesday June 21 2017, @05:15AM (1 child)
I persistently have a cash stack underflow error.
(Score: 4, Funny) by aristarchus on Wednesday June 21 2017, @06:19AM
And this is why I often recommend Slackware. Not just easy on your wallet, easy on your buffer stacks.
(Score: 2) by Lagg on Wednesday June 21 2017, @06:08AM
I literally died trying to figure out that title. Was scavenged by Buzzard and literally haunting him via lasagna sleepwalks to get this post out.
Also not going to address nature of bug because it's already a broken record up in here. But: This strikes me as a first world RAM privilege that someone forgot to check. It's an issue with the constants determining the minimum page set to allocate in the heap to stop boundary fails. 1MiB to me - with disclaimer of it being forever since I did a kernel project and I miss that shit so much - is some pretty heavy overhead for an MMU. Nothing I've written for kernelspace needs that much, unless I compile it to pad. So if I were to assume good faith I'd just say this is something kernel maintainers didn't think about because that's overhead that makes them reflexively nop. Whether or not we are officially first world puter enough to have such defaults these days I guess doesn't matter if the attack is realistic enough.
That, or: It's a Serious Flaw(TM)
http://lagg.me [lagg.me] 🗿
(Score: 5, Funny) by turgid on Wednesday June 21 2017, @01:46PM
I'm sick of this lax commie layabout lefty hippy cancer-ware. I'm upgrading from Slackware64-14.2 to Windows 10 straight away.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 1, Interesting) by Anonymous Coward on Wednesday June 21 2017, @04:26PM
That is the root of the problem in a lot of these modena exploits.
(Score: 0) by Anonymous Coward on Wednesday June 21 2017, @04:54PM
This is kind of new, at least for public knowledge. Yes, it's an extension of earlier techniques, but so is everything.
It had been thought that guard pages were decently reliable protection. It turns out that you can often disable them (via RLIMIT for example) or bypass them (via programs with large stack buffers) and do various other things (read the paper) to make the exploit work... AND THERE IS A C LIBRARY ISSUE THAT HITS MOST PROGRAMS.
At a place-which-shall-not-be-named which does government work, hackers call the technique "ass to mouth", named after some nasty porn thing. I guess it is because you're getting stuff from one place into some other place, and it makes a mess, and it is really nasty gross.
(Score: 0) by Anonymous Coward on Thursday June 22 2017, @02:37AM
https://community.ubnt.com/t5/UniFi-Wireless/IMPORTANT-Debian-Ubuntu-users-MUST-READ-Updated-06-21/m-p/1968252#M233999 [ubnt.com]
Also seen some elasticsearch startup problems on Ubuntu's 4.4.0-81. As always, test before updating production servers.
(Score: 1) by yetr on Thursday June 22 2017, @05:30PM
>- Recompile all userland code (ld.so, libraries, binaries) with GCC's
> "-fstack-check" option, which prevents the stack-pointer from moving
> into another memory region without accessing the stack guard-page (it
> writes one word to every 4KB page allocated on the stack).
Gentoo users never catch a break, do they?