Datatechvibe Explains: Dirty Pipe

Dirty Pipe allows for overwriting data in arbitrary read-only files, which can lead to privilege escalation by injecting code into root processes.

Dirty Pipe (CVE-2022-0847) is a security vulnerability in Linux systems discovered by Max Kellermann. While dealing with a service issue, the software engineer and hacker for IONOS subsidiary CM4all discovered the CVE. Customers were complaining about the inability to decompress access logs they had obtained. On one of the log servers, Kellermann discovered a corrupt log file. He could not explain why it was corrupt, but he was able to remedy the problem manually. After some time had gone, the identical problem arose again and again, months later. He figured out a pattern.

Kellermann stared over the code for hours, attempting to rule out every option. He concluded that the issue was caused by a defect in the Linux kernel, which is the operating system’s core. This is quite improbable because the kernel is a highly complicated project created by thousands of people, making it incredibly stable and dependable. As a result, Kellermann found the most critical security flaw for Linux systems and derivatives in the previous six years.

Many of us might remember CVE-2016-5195 as well – named Dirty Cow, which made headlines a few years ago. The vulnerability allowed the rooting of Android smartphones. Malicious applications that exploited the CVE were circulating at the time. Because Dirty Pipe is straightforward to attack, it poses a significant security risk to all Linux users. The Android operating system is also impacted because it is based on the Linux kernel.

Why is the CVE called Dirty Pipe?

Let’s go back to the fundamentals. The CPU manages memory in the form of memory pages. The kernel is in charge of these pages. A subsystem known as page cache exists. When writing to a file, the data is temporarily saved in the page cache until the backup device is available.

The online service that creates ZIP files connects with the web server through pipes in Max Kellermann’s unsuccessful log file compression scenario. As the name says, these pipelines have something to do with our CVE. But, first and foremost, what is a pipe? As described, a pipe is a data stream that connects two processes. In Linux, it enables unidirectional inter-process communication. This indicates that one program’s output is utilised as input for another program.

A page is assigned to a pipe and filled with data at the first write. Because a page may not be filled (room for 4KB of data), the next write will be added to the existing page rather than creating a new one. An anonymous pipe buffer is what it’s called.

Pipe data may have various statuses and permissions, necessitating pipe flags to display these details. The PIPE BUF FLAG CAN MERGE flag is one of them. A data buffer can be combined.

System calls are used to transmit requests from the userspace to the Linux kernel. Splice() is one such request. The kernel will load data from a file into the page cache and build a struct pipe_buffer pointing right within the page cache if we splice() data from a file into a pipe. This speeds up the operation since there is no need to transfer data into memory (“zero-copy”), as with anonymous pipe buffers.

What is the issue here?

Additional data transferred to the pipe may not be added to the page, unlike anonymous pipe buffers, because the page is held by the page cache, not the pipe. New functions allowing the allocation of new pipe buffers were introduced in 2016. The issue is that these functions did not properly initialise the flag variable. It became possible to create page cache references with any flags.

Those flags weren’t as essential back then, but that changed when the PIPE_BUF_FLAG_CAN_MERGE flag was created, checking if a pipe buffer could be merged. Because the kernel has complete control over the cache and there is no permission checking when writing to a pipe, it became feasible to erase data in the page cache.

By now, most of you must be clear about this type of vulnerability. This CVE lets users insert their data into sensitive read-only files, resulting in privilege escalation and total control over Linux machines and Android handsets.

All devices running Linux kernel versions since 5.8 are affected. This is bad news for any Linux gadget makers out there. As previously stated, this vulnerability impacts Android as well. Devices running Android 9-12 and Android T (also known as Android 13, AOSP experimental 2022) are particularly vulnerable.

How to fix the Dirty Pipe CVE?

Let’s look at what you can do to keep your systems safe against Dirty Pipe. Max Kellermann created a simple script to fix the CVE rapidly. All impacted Linux versions have already received the security update. The good news is that new kernel versions are now available (5.16.11, 5.15.25, and 5.10.102). In addition, Google has already fixed the Dirty Pipe CVE and released updated Android upgrades.

Having current software on hand, on the other hand, will only go you so far. These security fixes must be applied to all of your devices. If most of them are deployed in the field, this can be a challenging assignment. Dirty Pipe is the finest illustration of recurring security issues that can put whole device fleets at risk.

Over-the-Air (OTA) updates are the most practical method of delivering security fixes. You may respond quickly and flexibly to urgent situations by remotely applying vital security patches and bug fixes using OTA updates. There’s no need to update all of your devices manually.