Because of the vulnerabilities of Stack Clash, attackers can get access to full machines. So, this needs immediate attention from hosting providers which are offering shared hosting plans. In shared hosting, a single server is shared by many users and a compromised user will automatically affect all co-users.

What is Stack Clash?

Stack Clash essentially refers to many escalation privileges risks which can affect application stacks. This is the memory holding short term data needed for applications which grows as required. If an application’s stack is too big, it moves closer to the heap or the memory which has the data like files which can be viewed and edited. So, attackers can exploit this proximity and confuse the application. It starts to overwrite portions of the heap and stack and automatically hampers flow of execution of the app. Attackers thereby gain privileges of the program which has been so hijacked. These are all system-level reliable programs and when attackers get access to their root privileges they can assume total control over the system. This needs to be addresses right away because Unix-based systems are used extensively in server environments. Hosting providers have to ensure that systems are updated.

Things to remember about Stack Clash:

• It is important to understand that a local exploit can cause heavy damages. Even there is a remote exploit, it can never be ruled out. Moreover, attackers will not simply use a single vulnerability in an attack; they will chain them together to get better results. So, they may use remote exploits also to get the initial access into a network. When they get control over a vulnerable machine, they will then use Stack Clash to get root access to do other actions. So, simply because a server is not accessible remotely is no reason to ignore updating it.

• Stack Clash unfortunately bypasses the stack guard pages; when it had been exploited in 2010, a stack guard page was added to mitigate such attacks. This was to be the divider between the heap and stack. But these could be bypassed completely since the applications had not been designed with enough checks. So, having a stack guard page of only some kilobytes is useless. In case attackers “jump” this page, no page-fault alarm is raised. The stack can comfortably extend into the heap. It is necessary to raise sizes of stack guard pages.

• If the container security isolation methods work well, attackers can get access within the container but they cannot escape it to get root access to the machine. In VMs too, attackers may hijack programs which run on a vulnerable OS in that VM. However, these privileges are restricted to the VM. The attackers would then have to chain the Stack Clash with some other vulnerability to escape the container. The problem however is that most organizations depend upon VMs for easy management. So, when they have a VM and a multi-tenant environment inside it or if they set up a container which offers a shared hosting environment, Stack Clash can easily affect all users.

• It is believed that even if a server gets compromised because of attacks, the data stored in it stays safe if encrypted. However, attacks can access even encrypted data if the app which has got hijacked handles this data. When attackers gain root access, they can easily decrypt this data.

Moreover, administrators need to be test patches carefully before they apply the software updates. They may even decide to reduce the size of stack growth. When the limits are set too low, the programs are likely to crash. So, there must be proper testing to determine the right amount which applications will need to run properly. Even this method is not foolproof because exploits can bypass this. Usually the limits are not low enough to stop attacks.

To sum up, Stack Clash can work as it depends upon the details of the systems targeted like location of data, how code behaves etc. If details are in expected locations or if they can be guessed easily, attackers can get all the information they need. When attackers fail to guess details of target victims, attacks become impractical. The bottom line is that servers must be duly updated to address Stack Clash vulnerabilities. It is also important not to delay this because the damages can be extensive and any attack wave may lead to multiple systems collapsing.