A new CVE in the Linux kernel was released this week. CVE-2022-0847, aka “Dirty Pipe”, is a vulnerability that allows users on a Linux system to overwrite the contents of files that they can read but shouldn’t be able to write to. Looking at this vulnerability from the perspective of hosts using containerization software such as Docker, it was possible to modify files from container images on the host, from inside a container — something that generally shouldn’t be possible.
This could enable an attacker to effectively modify containers that are running against a shared image, or to poison an image on a host so that new containers would receive modified files.
To mitigate this issue, affected systems — those running Linux kernel 5.8 or above — should be patched immediately.
Technical details
The page that disclosed the vulnerability has details and great background, so we’ll focus here on the impact from a container perspective.
An essential part of modern containerization is the use of overlay file systems, where a shared read-only image is used to create running containers. When a user inside a container modifies a file from the underlying image, the original file should be copied to a new location specific to that container, and the modification applied there. The original file should remain unmodified.
Using the exploit provided by Max Kellermann in his blog, we can try to modify a file on the underlying system to see what happens.
The starting point is an Ubuntu 21.04 system running Docker 20.10.10, with no container images currently downloaded locally.
First, we start a container based on the ubuntu:21.04 image, which will pull a fresh copy of the image from Docker Hub. The exploit should work with any image but this one is a clean base.
We’ll then copy in our exploit code — just a compiled version of the code in the original vulnerability disclosure blog — and try to modify a file from the underlying image. As a demonstration, we’ll use /etc/shells.
Initially, we can see that our file contains the expected content:
Then, we run our exploit, attempting to add a string “Hello World” to the top of the file. We can see that it changed the file in that container, but that’s expected, because we’re the root user in that container.
Now we go back to the host and start a new container, based on the same image. The new container should *not* have the modified file:
And we can clearly see our modified file, so the exploit is working OK.
This exploit can affect existing containers, too. For example, if you had a host with 10 nginx containers using a shared image, and the attacker modified the nginx.conf file in one, it would instantly change the files in the others, too, as long as they were still using the file from the underlying image.
Another scenario for this exploit is one in which volumes are mounted from the host as read only because attackers can use this exploit to override that restriction.
Impact and mitigations
How serious this issue is will depend on the architecture of your environment. To exploit this issue, attackers must have access to a single container on the host. If they have that access and the kernel version is vulnerable, they can modify any files from the image that was used to create the container that they have access to, or any files that are mounted read only from the underlying host.
The issue is likely to have the most impact where there are many containers running with a shared image file and untrusted users can access individual containers but shouldn’t be able to modify files on the underlying host.
As with any Linux kernel vulnerability, the best advice is to upgrade regularly and reboot the host after you upgrade to ensure that the patch has been made effective.
