The Stack Clash vulnerability in Linux, Solaris and BSD-based systems would let attackers gain root privileges and take full control of the machine, Qualys researchers warned Monday. Hosting providers and administrators of shared environments need to pay particular attention to this flaw since one compromised user can result in all other users on the same server being compromised.
Stack Clash refers to a set of escalation privileges vulnerabilities (CVE-2017-1000364, CVE-2017-1000365 and CVE-2017-1000367, to name a few) affecting the application stack, a memory region that holds short-term data for applications which automatically grows as needed. When the application’s stack grows too large, it can get too close to the heap, the memory region that holds information such as the files being viewed and edited. Attackers can take advantage of the proximity of the two to confuse the application into overwriting parts of the stack and the heap. Doing so hijacks the flow of execution within the application.
“Our exploit grows the stack out, jumping past protections and getting into areas of memory where we should not be able to get code to execute,” said Jimmy Graham, director of product management at Qualys.
The attacker gains the privileges of the hijacked program. These aren’t just any run-of-the-mill applications, either. These are trusted, system-level programs such as sudo on Linux distributions such as Debian, Ubuntu, and CentOS; ld.so and SUID-root binaries on Debian, Ubuntu, Fedora, and CentOS; and rsh on Solaris. If the program has root privileges, the attacker takes over the whole system as an administrator. “This is a fairly straightforward way to get root after you’ve gotten user-level access,” Graham said.
The vulnerability is present in Unix-based systems on i386 and amd64 architectures. Affected Linux distributions include Red Hat, Debian, Ubuntu, SUSE, CentOS and Gentoo. Solaris is owned by Oracle. FreeBSD, OpenBSD and NetBSD are also impacted. Qualys has been working with distributions and vendors since May to get the vulnerabilities fixed, and the updates are just beginning to be released. Administrators need to act promptly to update affected machines with the security updates.
[Related: -->Self-protection is key to Linux kernel security]
Prompt attention is necessary, especially since Unix-based systems are predominantly used in server environments. Qualys didn’t research Microsoft or Apple products, and Graham could not say what kind of effect this kind of vulnerability may have on those systems.
Systems that must comply with specific regulations or contain critical data should take priority. Hosted providers and administrators managing shared environments need to make sure their systems are updated. If the user has shell access to the server, as is typical in multi-tenancy environments, then attackers can compromise that user and use Stack Clash to hijack applications running in that userspace. At that point, the attackers can jump to other userspaces in that shared environment.
The following are five things to keep in mind while assessing the risk Stack Clash pose to the organization.
1. Don’t underestimate the damage a local exploit can do
Qualys researchers didn’t find a remote exploit, but was unable to rule it out. That is an important distinction. Just because they didn’t find it doesn’t mean it isn’t possible. It all depends on how the program was built. Qualys looked at Exim mail server on Debian, and it was “sheer luck” that it was not remotely exploitable, Graham said.
Attackers also rarely use just one vulnerability during an attack, as they get better results by chaining them together. Stack Clash is a powerful tool for attackers to have in their arsenal while they are moving laterally through a compromised network. They can use a remote exploit or other means to get the initial foothold into the network, but once they are on a vulnerable machine, they can use Stack Clash to gain root access and perform other actions. For example, a vulnerability in sudo fixed recently (CVE-2017-100367) could be combined with Stack Clash to be able to run arbitrary code with the highest privileges. Just because the server is not remotely accessible is not good enough reason to make updating it less priority.
2. Stack guard-pages prevents this class of attacks
Actually, the bad news is it doesn’t. In fact, Stack Clash completely bypasses stack guard-pages. The concept behind Stack Clash has been well-understood since 2005, and after it was exploited back in 2010 (CVE-2010-2240), the Linux kernel added stack guard page to mitigate this class of attack. The guard-page acts as a divider between the stack and the heap. However, Qualys researchers were able to bypass the guard pages entirely because the applications were not built with sufficient stack protection checks in their code.
“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,” Qualys researchers wrote in the advisory. “We show that stack clashes are widespread in user space, and exploitable despite the stack guard-page.”
The size of the stack guard-page should be increased to 1MB at a minimum as a short term workaround until updates can be applied.
3. Stack Clash doesn’t affect virtual machines and containers, but…
Yes and no. Stack Clash is a local exploit in the user space and not the operating system itself. This means that if container security isolation, like namespaces and cgroups, are working properly, the attacker can gain root within the container but wouldn’t be able to escape the container to gain root privilege on the machine. It shouldn’t be possible to jump from chroot to chroot, but only if that segmentation was done properly.
The same goes for virtual machines (VMs). The attacker can hijack the program running on a vulnerable operating system within a virtual machine, but the elevated privileges will remain within the confines of the VM itself. Attackers would need to chain Stack Clash with another vulnerability that could break out of the container or the VM.
[Related: -->Why Linux users should worry about malware]
However, there is a caveat, and a huge one. Many organizations rely on VMs and containers to make deployment and management simpler. If they set up a VM and then set up a multi-tenant environment within, or a container hosting a shared environment, then Stack Clash would affect all the users within those VMs and containers, said Gounares. At that point, it no longer matters if the underlying system is bare-metal, virtual machine, or container, as one compromised user within the environment will lead to other users being compromised.
It's also worth noting that the Stack Clash is difficult on 64-bit environments, and Docker containers run on 64-bit by default. There is also a Docker option to limit the container image's stack size, by adding the flag --ulimit stack=[size]. Make sure the size value isn't too low as that may affect normal application behavior. Setting the option will ensure "the stack will never reach the heap," said Daniel Shapira, a security researcher with Twistlock.
4. Data is encrypted, so even if the server is compromised, the data is safe
Absolutely not. If the data stored on the servers are encrypted, kudos. But Stack Clash attacks can still succeed in accessing the encrypted information if the application that gets hijacked is the one that handles the data. With root access, the attackers have full control over the box and can access the application that can decrypt the data.
5. Use the workaround, but it isn’t foolproof
Administrators must be careful about applying software updates to servers, especially since the patches have to be tested carefully to make sure there are no potential issues. Rebooting production servers also require a lot of advanced planning. As a workaround, administrators can decide to limit how big the stack can grow by setting the RLIMIT_STACK and RLIMIT_AS resources of local users and remote services, but that poses its own set of challenges.
If the stack limit is set too low, programs will crash because the applications cannot pass the parameters they need in course of normal operations. Testing will be required to find the optimal amount the application needs to calculate the maximum, and figuring that out accurately is difficult because a lot of edge cases need to be tested.
There’s the possibility that exploits will still be able to bypass the workaround. “Use this workaround at your own risk. Most likely your limits will not be low enough to resist all attacks,” Qualys wrote in the advisory. Some of the exploits crafted by Qualys allocated just 137 MB of heap memory and “almost no” stack memory, and that kind of limit is way too low for modern applications.
Rebuilding and reinstalling the dynamic library ld.so and recompiling all programs using gcc's -fstack-check option would prevent the stack pointer from moving into other memory regions. This will require all the programs to be recompiled -- an expensive endeavor to be sure, but it would prevent Stack Clash completely.
Randomize memory to make attacks more time-consuming
The proofs of concept by Qualys followed four sequential steps, which include: clashing the stack with another memory region, running the stack pointer to the start of the stack, jumping over the stack guard-page, and writing to the memory region to smash the stack or other memory region. In the last step, to write to the memory region, Qualys was able to brute-force ASLR (Address Space Layout Randomization) because it used only 8-bits of entropy.
[Related: -->Eleven-year-old root flaw found and patched in the Linux kernel]
Stack Clash works because it relies on predictable details of target systems, such as where data is stored, and how code will behave, says Gounares. When the details are in expected places or can be easily guessed, attackers can just brute-force the information they need to know. The Qualys exploit took just five hours to brute-force ASLR by running through all possible combinations, for example.
“If the attacker doesn’t know and can’t guess details of their target victims, attacks like Stack Clash become impractical—even if the underlying bugs they exploit still exist,” Gounares says.
Everyone will need to update their servers to address Stack Clash, and considering the kind of damage possible, everyone should do it soon before the wave of attacks start knocking over the vulnerable systems.