Categories
Uncategorized

What is Dirty Pipe Vulnerability and it’s impact on Containers?

Disclosure

A new Critical Linux vulnerability was disclosed to the public on 7th March by Max Kellermann. It’s tracked as CVE-2022-0847 and has a severity score of 7.8 (HIGH).

This Dirty Pipe Vulnerability is similar to Dirty Cow Vulnerability, recorded as CVE-2016-5195. But, is much easier to exploit. Dirty Cow vulnerability was surfaced in October 2016.

This vulnerability is called Dirty Pipe Vulnerability since it enables attackers to perform insecure interactions between Linux files and Linux Pipe (in-memory data buffer), which can act like a file. Even though the file is flagged as read-only, modifying the in-memory copy acts as a write to the file system.

To read and understand how Max analyzed the bug, go here. It has all the nitty-gritty details and has all the background around the vulnerability.

 

Impact

This allows escalation of privileges, as part of the unprivileged process, by injecting code into root processes and overwriting data in arbitrary read-only files. And this could let attackers take control of vulnerable systems.

Kellermann highlights, “To make this vulnerability more interesting, it not only works without write permissions, it also works with immutable files, on read-only btrfs snapshots and on read-only mounts (including CD-ROM mounts). That is because the page cache is always writable (by the kernel), and writing to a pipe never checks any permissions.”.

For Container workloads, if exploited, a user in a running Docker container can overwrite files in the image. This would mean attackers can modify files in the host from the container, which generally should not be allowed and possible.

Depending on the architecture of your Containers’ environment, it could be serious. If an attacker gets access to a single container on the host (in a vulnerable kernel), an attacker can modify the image itself or the files in read-only mounts from the host. If a shared image file is used by many containers, an attacker can make the most damage.

 

Identification

Max has shared his Proof Of Concept exploit here.

Here are a few simple commands for a PoC.

 

Simply run uname -r to check your kernel version. If it’s 5.10.1025.15.25, or 5.16.11 then you are okay.

 

Mitigation

If you are on Kernel 5.8 or higher, it definitely needs to be patched. Currently, there is no mitigation available for this flaw. Customers should update to fixed packages, once they are available.

Kellermann explained that the vulnerability affects Linux Kernel 5.8 and later versions but was fixed in Linux 5.16.11, 5.15.25, and 5.10.102.

Linux released fixes (5.16.115.15.255.10.102) on February 23, and Google merged Kellermann’s bug fix into the Android kernel on February 24.

 

Patches:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d2231c5d74e13b2a0546fee6737ee4446017903

https://security-tracker.debian.org/tracker/CVE-2022-0847

https://access.redhat.com/security/vulnerabilities/RHSB-2022-002

https://ubuntu.com/security/CVE-2022-0847

It’s always recommended to upgrade the kernel regularly and reboot the host post-upgrade. This will ensure that the patches are enabled and effective. This applies to all the Linux kernel vulnerabilities.

 

How can Cloudanix help?

Cloudanix helps you to improve your Cloud Security. Our platform offers CSPM, CIEM, and CWPP (Container Vulnerability) all in one – so your Kubernetes-based workloads running in any cloud or bare-metal can be secure. You can sign up for a free trial here today!