Stack Clash flaws blow local root holes in loads of top Linux programs
We knew about this in 2005. And 2010. And people are still building without -fstack-check
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.
The issue was first noted by security researcher Gaël Delalleau in 2005, and the vulnerability resurfaced in 2010 when another researcher, Rafal Wojtczuk, noted similar issues while running an Xorg server running on Linux. Fixes were issued after both discoveries.
You may have thought that would be the end of it. Qualys noted on Monday: "The only public exploits are Gaël Delalleau's and Rafal Wojtczuk's, and they were written before Linux introduced a protection against stack-clashes (a 'guard-page' mapped below the stack)."
However, it now looks like stack clashes remain possible despite the added protections – mainly because developers weren't building their code with sufficient stack protection checks. In other words, the guard pages mitigated the threat, but thorough stack protection checks weren't employed by programs, allowing them to be attacked and hijacked.
"In this advisory, we show that stack clashes are widespread in user space, and exploitable despite the stack guard-page," Qualys' researchers wrote. "We discovered multiple vulnerabilities in guard-page implementations, and devised general methods for:
- 'Clashing' the stack with another memory region: we allocate memory until the stack reaches another memory region, or until another memory region reaches the stack.
- 'Jumping' over the stack guard-page: we move the stack-pointer from the stack and into the other memory region, without accessing the stack guard-page.
- 'Smashing' the stack, or the other memory region: we overwrite the stack with the other memory region, or the other memory region with the stack."
The team said they were able to develop 14 exploits and proof-of-concept attack code for software on Linux, OpenBSD, NetBSD, FreeBSD and Solaris on 32-bit and 64-bit x86 processors. We're talking about programs like Sudo on Debian, Ubuntu, and CentOS; Exim on Debian; ld.so and most SUID-root binaries on Debian, Ubuntu, Fedora, and CentOS; rsh on Solaris 11; and so on. Red Hat Enterprise Linux 5 to 7, Enterprise MRG 2.5, and Virtualization, and RHEL Atomic Host, are also among distros affected by Stack Clash.
Fixes have already been issued or are coming soon for these packages – so check, fetch and install security updates using your favorite management tool if you're using any of the affected software. The fix, by the way, is to rebuild and reinstall the dynamic library ld.so and executables with gcc's -fstack-check feature, which should kill Stack Clash dead.
All of the examples allow local privilege escalations on a Linux or Unix-ish system, giving a logged-in miscreant, or someone who has gained a normal user shell on a system, the leverage they need to take over the box. As far as the researchers know, these can't be exploited remotely, for now, at least. ®
Sponsored: What next after Netezza?