Background
I was reading about the Stack Clash vulnerability last night and it seems that this is something which has been around before, been fixed twice and then another method to trigger the exploit has been identified but as it has been rated 'Important' I thought I'd write a blog about it. As with most aspects of security, it's a game of 'cat and mouse' and the goal is always a moving target!
The long and short of it is, there are updates to the Linux kernel and glibc packages which will 'fix' the issue. On the Loadbalancer.org appliance, we have a custom compiled kernel and so this is not likely to be 'fixed' until the next release where we're moving to a newer kernel anyway. Should you wish to update the glibc package then this can be done by executing the following command on your Loadbalancer.org appliances. :
yum update glibc
The reason for the quotes and the generally relaxed approach to the situation is simple; this exploit relates to privilege escalation (i.e. giving a standard user account root level access) which is a moot point on the Loadbalancer.org appliance as the default configuration is with full root level privileges. At present, the only successful proof of concept exploit implementations for this advisory have been locally executed (i.e. on the box) and if this is the case and you find yourself in this situation, then there are probably many other questions to be answering first! As far as I am aware, there have not been any successful remote access attempts to exploit this situation, or at least any situations.
Resolution
You can update the glibc package on your Loadbalancer.org appliances and when the new update is available (v8.2.6), it will contain a new kernel which should be patched against this exploit. We always advise customers to change their passwords & SSH keys from the defaults and where feasible, use iptables to control access to their load balancer - all of these things can be achieved using the "lbsecure" tool. Similar to keeping warm in the winter, security is best achieved with layers and if there is any potential that the load balancer can be accessed remotely, ensure your perimeter firewall is suitably configured to your requirements.
If there are any questions, please contact our support team and our engineers will be happy to help!
References
- Qualys blog on Stack Clash - https://blog.qualys.com/securitylabs/2017/06/19/the-stack-clash
- Red Hat vulnerability response - https://access.redhat.com/security/vulnerabilities/stackguard
- Loadbalancer.org v8.2 Administration Guide - http://pdfs.loadbalancer.org/v8/loadbalanceradministrationv8.2.pdf#page=67
