It's only March and the next security vulnerability is already making its way into the headlines. It feels like software developers and solution builders have barely taken a breath after Log4J and it’s already time to react to the next big security revelation – Dirty Pipe.
Dirty Pipe (CVE-2022-0847) is a security vulnerability in Linux systems that was discovered by Max Kellermann (official Statement). The software developer and hacker, who works for IONOS' subsidiary CM4all, stumbled upon the CVE while dealing with a support ticket. Customers were complaining about access logs they downloaded that could not be decompressed. Kellermann found a corrupt log file on one of the log servers. He could not explain why it was corrupt but fixed the issue manually. Some time passed but the same issue kept popping up, again and again, months later. He discovered a pattern.
Kellermann spent hours staring at code trying and eliminating every possibility. He concluded that the problem must be a bug in the Linux kernel, the core of the operating system. This is usually very unlikely since the kernel is an extremely complex project developed by thousands of individuals making it extremely stable and reliable. To put it in Sherlock Holm's words: “When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth”. Thus, Kellermann discovered the most serious security vulnerability for Linux systems and their derivatives within the last 6 years.
Some may remember, CVE-2016-5195, also called Dirty Cow, which made headlines 6 years ago. The vulnerability allowed the rooting of Android smartphones. At the time, malicious apps that exploited the CVE were spreading. Dirty Pipe is comparatively easy to exploit and thus poses a massive security risk to all users of Linux-based devices. Since the Android operating system is based on a Linux kernel it is also affected.
Let’s summarize some basics. Memory is managed in the form of memory pages (4 KB per page) by the CPU. These pages are handled by the kernel. There is a subsystem called page cache. When writing to a file the data is temporarily stored in the page cache until it gets stored in the backing device.
In Max Kellermanns’ case of failing compression of log files, the web service that generates ZIP files communicates with the web server via pipes. As the name Dirty Pipe suggests, these pipes have something to do with our CVE. But what is a pipe? Simply put, a pipe is a stream of data that passes between two processes. It realizes unidirectional inter-process communication in Linux. This means that the output issued by one program is used as input for another program.
During the first write to a pipe a page is allocated to it and filled with data. A page is not necessarily filled completely (space for 4 kB worth of data), therefore, the next write will be added to that existing page instead of allocating a new one. This is called an anonymous pipe buffer.
Data within pipes might have a different status and permission, therefore they need pipe flags to show these specifications. One of those flags is the PIPE_BUF_FLAG_CAN_MERGE flag. It states that a data buffer can be merged.
To send requests from the userspace to your Linux kernel system calls are used. One of those requests is splice(). If we splice() data from a file into a pipe, the kernel will load the data in the page cache and will create a struct pipe_buffer pointed directly inside the page cache. This speeds up the process since no data has to be copied into memory ("zero copy"), which would be the case with anonymous pipe buffers.
Unlike anonymous pipe buffers, additional data written to the pipe may not be appended to the page, since the page is owned by the page cache, not the pipe. Back in 2016 new functions were introduced enabling the allocation of new pipe buffers. The problem is that these functions missed the initialization of the flag variable. In this way, it became possible to create page cache references with arbitrary flags.
Back then those flags were not that important, but this changed because the PIPE_BUF_FLAG_CAN_MERGE flag was introduced, which is responsible for checking if a pipe buffer can be merged. And this is how it became possible to overwrite data within the page cache since the kernel is in full control of the cache and there is no permission checking when writing to a pipe.
Most of you will have a pretty good idea by now what is possible when exploiting this kind of vulnerability. This CVE allows any user to inject their own data into sensitive read-only files, thereby gaining privilege escalation and complete control over devices running on Linux or smartphones powered by Android.
Affected are all devices with Linux kernel versions since 5.8. This is bad news for all providers of Linux devices out there. As mentioned above this vulnerability also affects Android. In particular, devices running on Android 9-12 and Android T (also referred to as Android 13, AOSP experimental 2022) are under threat.
However, having updated software on hand will only help you so much. You need to deploy these security patches to all your devices. This can be a challenging task if most of them are deployed in the field. Dirty Pipe is the best example of occurring security risks that can put whole device fleets at risk.
The most reasonable channel through which to deliver security patches is Over-The-Air (OTA) updates. With OTA updates you can respond fast and flexibly to critical situations by rolling out important security patches and bug fixes remotely. There is no need to update all devices manually.
We at emteria included the security patch directly in our Android image for Raspberry Pi 4 Model B (v11.6.0), the RPi Compute Module 4 (v11.7.0), and RPi 400 Personal Computer Kit (v11.7.0). We strongly encourage our customers to update their Raspberry Pi devices as soon as possible to ensure full security. RPi3 and CM3 devices are not affected. Simply use the OTA update functionality of emteria Device Hub to easily update your devices and stay one step ahead of possible attacks.
Without emteria Device Hub providing robust and secure updates can be difficult. We have summarized the necessary requirements for a successful Android Over-The-Air update management based on our experience and best practices implemented by our customers.
Learn more in our OTA Update Management Checklist.
Interesting links and sources