Vulnerabilities

Containers Can’t Fence Dirty COW Vulnerability

The Dirty COW vulnerability in the Linux kernel that was revealed late last month can’t be mitigated with the help of containers, security researchers have discovered.

<p class="MsoNormal"><span><span style="font-family: &amp;quot;"><strong><span>The <a href="http://www.securityweek.com/dirty-cow-linux-kernel-flaw-exploit-seen-wild">Dirty COW vulnerability</a> in the Linux kernel that was revealed late last month can’t be mitigated with the help of containers, security researchers have discovered.</span></strong></span></span></p>

The Dirty COW vulnerability in the Linux kernel that was revealed late last month can’t be mitigated with the help of containers, security researchers have discovered.

The flaw (CVE-2016-5195relies on a race condition in the kernel, between the operation that performs writes to copy-on-write (COW) memory mappings, and the one that continuously disposes of that memory. When the race condition appears, the kernel might end up writing data to read-only memory mapping, instead of making a private copy first.

Proof of concept (POC) exploit codes that leverage the vulnerability have already started to emerge, including some targeted at Android devices. These POCs revealed that one can write to read-only files, and that root access could be achieved, and even how to break out of a container.

Aqua Security Software researchers explain that the available POCs focused on privilege escalation inside the container, but that it is possible to run code inside a container, from a non-root user, to write data to a “protected” file on the read-only volume the container was mounted on.

Aqua’s Sagie Dulce explains that even users with root privileges shouldn’t have write access to a mapped read-only volume in a container, let alone a non-root user. However, Dirty COW makes it possible for data on the host to be manipulated from within the container.

Next, the researchers tested their code in a container with user namespace, as a non-root user inside the container. When running with user namespace, the root user inside the container is mapped to a non-root UID (a non-privileged user) on the host. The test revealed that, even if the user in the container was non-root and it shouldn’t have root on the host, the code would still write to the “protected” file on the host.

“In conclusion, when it comes to kernel vulnerabilities, you can’t be too careful. Containers still share the same kernel, which when exploited has the potential of jeopardizing other containers or the underlying host. We saw that a simple POC, which was not meant to break out of a container, could still modify data on the host,” Aqua’s researcher notes.

Others too have discovered that containers such as Docker can’t keep systems safe from Dirty COW. Paranoid Software explains that they decided to exploit the vDSO (virtual dynamic shared object) feature in Linux, because this small shared library is automatically mapped by the kernel into the address space of all user-space applications.

A POC available on GitHub uses Dirty COW to modify the clock_gettime() function in the vDSO memory space for all callers, not just the running process. “Once the race condition is triggered, and the shellcode executes, it will send you a root shell,” Paranoid Software’s Gabriel Lawrence says. The researchers published a video demonstrating the exploit.

Advertisement. Scroll to continue reading.

“I’m particularly interested in demonstrating escaping out of Docker simply because I think many people overestimate what is required. Kernel exploits are rarer than user space escalations, but they are not without example – and understanding that even with the separation offered by the kernel features that make containers possible, it’s possible to get past them with a kernel exploit,” Lawrence notes.

Related Reading: Disrupting the Disruptor: Security of Docker Containers

Related Content

Copyright © 2024 SecurityWeek ®, a Wired Business Media Publication. All Rights Reserved.

Exit mobile version