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 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