“Dirty Pipes” in the Kernel

A few years ago, a vulnerability dubbed “Dirty Cow” (CVE-2016-5195) was in the spotlight for a while. It was a trivially exploitable privilege escalation path that basically affected any Linux distribution and was exploited in the wild extensively. That vulnerability abused the Kernel’s Copy-On-Write (COW) mechanism and was sometime later found to be remotely exploitable through web servers that allowed file uploads.

On the 7th of March of 2022, a similar vulnerability was disclosed, also affecting all recent Linux distributions, nicknamed “Dirty Pipe” (CVE-2022-0847). It lets an unprivileged user overwrite any file, or part of a file, in a Linux system, even read-only ones. Several variants have already been disclosed that allow for the replacement of SUID files.

Patches for CVE-2022-0847 will be made available through KernelCare in the coming days, and this post will be updated with availability information as each becomes ready. At this moment, vulnerable kernel versions include 5.8 and onwards, with the flawed commit having been backported to multiple 4.x versions as well.

[Update 9th March: Updates for RHEL 8 and Oracle EL 8 are now available for deployment. Further patches are being prepared for other distributions.

Update 10th March: Updates for CentOS8, Almalinux 8, Rocky Linux, Ubuntu 20.04, CloudLinux 8 and CloudLinux 7h are also completed and are going to show up on feeds.

Update 11th March: Another batch of updates released for Ubuntu 18.04, Proxmox VE5 and Proxmox VE6.]

To understand the underlying flaw behind CVE-2022-0847, it is important that we first offer some brief information regarding CVE-2016-5195. “Dirty Cow” was possible because a race condition was found in the Copy-On-Write subsystem within the kernel. As a result, an unprivileged user could write in otherwise unreachable memory locations through this flaw. This would “dirty” those memory locations, hence the name. Moving from this to an elevation of privilege is a trivial operation for any properly motivated malicious actor, and in fact, that is precisely what happened. While “Dirty Cow” started as a local-only exploit, it was soon discovered that web servers that had the option to accept uploads from users could also be used as an attack vector. Hence, the vulnerability turned out to be remotely exploitable.

Fast forward a few years, and now IT teams are faced with “Dirty Pipe”, or CVE-2022-0847 if you think nicknaming vulnerabilities is not a very professional thing to do. As the name suggests, the flaw this time lies in the pipe handling code. Pipes are used as a way to pass information between processes. The most visible way pipes are used is when chaining commands, passing the output from one to the next through a “pipe”. Note that pipes can be created directly in code rather than simply used in the shell by an end-user or script.

It turns out that code introduced in this commit to the Linux Kernel “refactored” the way pipe flags (a way to control pipe behavior) are handled. You can read the extensive process behind the discovery of this vulnerability here.

Long story short, it became possible to write user-controlled content at an also user-controlled location in any file within the system (note that, since everything in a Linux system is technically a “file”, new variants of this vulnerability may introduce new, as-of-yet unknown behaviors). For example, introducing new content into /etc/shadow, or other, more subtle, ways of manipulating a system.

Since the exploit code is trivial, it is already widely available online (while not a deterrent, we try to refrain from posting direct links to exploit code on our blog). Because pipes are a basic functionality of the Kernel, the potential risk posed by this vulnerability is very high. It is also noteworthy that several variants have already been found, where the same flaw is used to abuse other system components rather than just writing directly to otherwise unwritable files. It is not that far-fetched to imagine that remotely exploitable attack vectors will surface in the coming days, just like they appeared for “Dirty Cow” in 2016.

For a quick check customers might want to verify the kernel version in use. Kernels before 5.8 and starting with 5.16.11, 5.15.25, 5.10.102 are not affected. Other Kernel versions may depend on specific backporting policies by each vendor and are currently being evaluated.

Updates for RHEL 8, Oracle EL 8, CentOS8, Almalinux 8, Rocky Linux, Ubuntu 18.04, Ubuntu 20.04, Proxmox VE5, Proxmox VE6, CloudLinux 8 and CloudLinux 7h are now available for deployment through KernelCare Enterprise. Further patches are being prepared for other distributions. IT teams are strongly encouraged to patch this vulnerability as soon as possible. TuxCare’s patches for KernelCare Enterprise will be made available shortly, and this post will be updated to reflect the actual availability of these patches when each is released.

TuxCare’s KernelCare Enterprise is providing live patches for “Dirty Pipe” even when the original distribution vendor is not able to do so with their own live patching solution.

Through KernelCare Enterprise, receiving patches for this and other vulnerabilities can be done without disrupting running workloads or having to reboot systems. If you would like to know more about KernelCare Enterprise and other TuxCare products, please check here.