SoylentNews is people
SoylentNews
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) 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.