.png)
Security researchers have discovered more than a decade-old vulnerability in several Unix-based operating systems — including Linux, OpenBSD, NetBSD, FreeBSD and Solaris — which can be exploited by attackers to escalate their privileges to root, potentially leading to a full system takeover.
Dubbed Stack Clash, the vulnerability (CVE-2017-1000364) has been discovered in the way memory was being allocated on the stack for user space binaries.
Exploiting Stack Clash Bug to Gain Root Access
The explanation is simple: Each program uses a special memory region called the stack, which is used to store short-term data. It expands and contracts automatically during the execution of any program, depending upon the needs of that program.
According to researchers at Qualys, who discovered and reported this bug, a malicious program can attempt to use more memory space than available on the stack, which could overflow the memory, causing it to collide or clash with nearby memory regions and overwrite their content.
Moreover, the Stack Clash exploit can also bypass the stack guard-page, a memory management protection introduced in 2010, after this issue was exploited in 2005 and 2010.
“Unfortunately, a stack guard-page of a few kilobytes is insufficient: if the stack-pointer ‘jumps’ over the guard-page—if it moves from the stack into another memory region without accessing the guard-page—then no page-fault exception is raised and the stack extends into the other memory region,” an advisory published by Qualys read.
The Stack Clash vulnerability requires local access to the vulnerable system for exploitation, but researchers said it could be exploited remotely depending upon the applications.
For example, a malicious customer with low privilege account with a web hosting company, running vulnerable system, could exploit this vulnerability to gain control over other websites running on the same server, as well as remotely gain root access and execute malicious code directly.
Just yesterday, we reported that how a web hosting company fell victim to a similar attack used to infect Linux servers with a ransomware malware, causing the company to pay more than $1 Million in ransom to get back their files.
Attackers can also combine the Stack Clash bug with other critical vulnerabilities, like the Sudo vulnerability recently patched, and then run arbitrary code with the highest privileges, said Qualys researchers.
7 Proof-of-Concept Exploits
The researchers said they were able to develop seven exploits and seven proofs of concept (PoCs) for the Stack Clash vulnerability, which works on Linux, OpenBSD, NetBSD, FreeBSD and Solaris on 32-bit and 64-bit x86 processors.
However, the researchers have not yet published the exploits and proofs of concept, giving users and admins enough time to patch their systems before they go into the Stack Clash exploits public.
The PoCs follow four steps, which include ‘Clashing’ the stack with another memory region, running the stack pointer to the stack’s start, ‘Jumping’ over the stack guard-page and ‘Smashing’ the stack or the other memory regions.
Among distros and systems affected by Stack Clash include:
- Sudo on Debian, Ubuntu, and CentOS
- ld.so and most SUID-root binaries on Debian, Ubuntu, Fedora, and CentOS
- Exim on Debian
- rsh on Solaris 11 and so on
- Red Hat Enterprise
The company also believes that other operating systems, including Microsoft’s Windows, Apple’s OS X/macOS and Google’s Linux-based Android OS could also be vulnerable to Stack Clash, though it is yet to be confirmed.
Patch Available; Update Now
Many affected vendors have already issued security patches for the bug, so users and administrators are advised to install patches a soon as possible.
If security patches from your vendor are yet to be released, you can reboot your systems or can manually apply stack limits to local users’ applications. Simply, set the hard RLIMIT STACK and RLIMIT_AS of local users and remote services to a low value.
It is also recommended to recompile all userland code (ld.so, libraries, binaries) with the –fstack-check feature. This would prevent the stack pointer from moving into another memory region without accessing the stack guard-page and would kill Stack Clash dead.
