Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

5 things you need to know about Stack Clash to secure your shared Linux environment

Fahmida Y. Rashid | June 21, 2017
Attackers can locally exploit the privilege escalation vulnerability to gain root access over Linux, Solaris and BSD machines. This is bad news for Unix-based servers, and even more so for multi-tenant environments.

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.

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.


Previous Page  1  2  3  4  Next Page 

Sign up for Computerworld eNewsletters.