The recently discovered ‘Stack Clash’ vulnerability in Linux-based systems is another critical security issue like Dirty Cow, but can the stack clash vulnerability affect containers, and what could an attacker do?
The short answer is yes, an attacker could exploit the vulnerability to gain root privileges within a container, but not necessarily be able to break out from the container. However, if the exploit occurs in the user space on the host, the escalation to root on the linux host itself is a critical security event which the attacker could use to compromise running containers or the Docker daemon itself.
The Stack Clash Vulnerability
This vulnerability (CVE-2010-2240) was recently discovered by security vendor Qualys researchers and has been named “Stack Clash” because it involves “clashing” the stack with another memory region, such as the heap. A flaw was found in the way memory was being allocated on the stack for user space binaries, which could allow an attacker to jump over the stack guard gap. This could cause controlled memory corruption on the process stack or the adjacent memory region, and thus increase their privileges on the system.
Stack guard-pages, which were designed to prevent such issues, can be bypassed by Stack Clash, as demonstrated by the Qualys researchers. Affected Linux distributions include Red Hat, Debian, Ubuntu, SUSE, and CentOS, and most distributions have issued fixes already. While this is a local exploit in the user space, it can still give attackers a foothold into the operating system or kernel. Stack Clash could be used with other exploits to wreak even more havoc on systems and potentially move laterally. For example, a recent sudo vulnerability (CVE-2017-100367) could be combined with Stack Clash to be able to run arbitrary code with root privileges.
Stack Clash in Containers
Although Stack Clash is a user space exploit which in a container would be confined to the container, it can still be dangerous. If container security settings, such as namespaces and cgroups, are configured properly, even if the attacker escalated to root within the container they wouldn’t be able to escape the container. But that’s a big IF. Attackers could combine Stack Clash with another vulnerability that could break out of the container or the VM, starting what is typically called the security ‘kill chain.’
Securing Containers and Hosts Against Stack Clash and Other Exploits
Because it’s possible to have the Stack Clash vulnerability affect containers, precautions against a resulting container break out should be taken. There are several points where the vulnerability and a real-time exploit can be detected, starting with scanning of the host and container and adding break out detection during run-time.
A specialized container security solution like NeuVector can provide multiple detection and prevention points against these types of exploits:
- Scan all hosts and containers in real-time for the vulnerability
- Monitor hosts and containers for privilege escalations during run-time
- Detect break outs or other attempts to move laterally from hosts or containers
- Block suspicious connections or quarantine suspicious containers.
It’s always advisable to periodically audit and test security settings against industry standard security benchmarks such as Docker Bench and the Kubernetes CIS Benchmark. However, it’s not always possible to detect vulnerabilities before they are exploited, especially for zero-day attacks. That is why a whitelist-based run-time security solution which can distinguish authorized connections from suspicious ones is a critical requirement for securing containers.
