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

 

Previous Page  1  2  3  4  Next Page 

Sign up for Computerworld eNewsletters.