DirtyPipe (CVE-2022-0847) – the new DirtyCoW?

A few days ago, security researcher Max Kellermann published a vulnerability named DirtyPipe which was designated as CVE-2022-0847. This vulnerability affects the Linux kernel and if exploited, can allow a local attacker to gain root privileges. The vulnerability gained extensive media follow-up, since it affects all Linux-based systems with a 5.8 or later kernel, without any particular exploitation prerequisites.

In this blog post we provide an overview of the DirtyPipe vulnerability and guidance on how to remediate, as well as a mitigation option we’ve discovered as part of our research on this vulnerability.

What is the DirtyPipe vulnerability (CVE-2022-0847)?

DirtyPipe is a local privilege escalation vulnerability in the Linux kernel that allows a local attacker to bypass any file permission, and write arbitrary data to any file under certain conditions. The vulnerability affects the Linux kernel starting with version 5.8 and was fixed in the latest kernel versions – namely 5.16.11, 5.15.25, and 5.10.102.

This vulnerability is similar to the DirtyCoW vulnerability that was discovered in 2016, in that it allows writing data to read-only resources. However, the main difference is that DirtyPipe allows the attacker to write to read-only files, whereas DirtyCoW allows writing to read-only-memory maps.

Technical summary of CVE-2022-0847

CVE-2022-0847 was discovered while using the splice() system call. Basically, this system call moves data between a file descriptor and a pipe, without requiring the data to cross the usermode/kernelmode address space boundary, which helps compute performance. Normally, when sending a file, memory pages (usually sized at 4KB) are copied into a memory-managed space called the page cache. From there the data is being copied to the userspace and remains in the cache to avoid unnecessary hard disk I/O.

When a file is being read into a pipe (via the splice() syscall) and at the same time arbitrary data is written into the pipe, the erroneous state caused by the bug causes the data to end up in the same page cache that is used by the file, and as such the data written to the pipe ends up at the file, even if the file was opened with read-only mode (O_RDONLY). We highly recommend the technical write-up for more details.

The vulnerability allows a local attacker to write arbitrary data to any file, regardless of permissions, under the following conditions:

1. File must be readable by the attacker
2. The overwritten offset must not be on a page boundary (page size is usually 4096)
3. The write cannot cross a page boundary
4. File cannot be resized
5. File must be backed by the page cache (ex. a regular file)

Who is affected by CVE-2022-0847?

CVE-2022-0847 affects Linux kernels from 5.8 until any version before 5.16.11, 5.15.25, and 5.10.102. Since this issue involves commonly used code in the Linux kernel it affects all major Linux distributions including Ubuntu and Debian under the default configuration.

Are cloud providers affected by CVE-2022-0847?

Currently, all major cloud providers are still affected and the vulnerability can be exploited on instances provisioned from AKS, EKS and GCP.

Are JFrog products vulnerable?

JFrog’s security team has conducted an internal research regarding this issue, and concluded that JFrog products are not vulnerable to this issue.

What is the impact of CVE-2022-0847?

The vulnerability can be easily exploited by local attackers to gain root privileges, for example by rewriting sensitive files such as “/etc/passwd” or hijacking any setuid-root binary by overwriting the ELF with malicious code.

Can CVE-2022-0847 be used to escape a container?

Under normal conditions, the vulnerability should not allow an attacker to escape a container, since normally files mounted in the container are not preserved by the host. However, in situations where sensitive host files are mounted read-only in the container, the vulnerability will allow the attacker in the container to modify them and possibly break out of the container (depending on the usage context of these files).

Note that CVE-2022-0847 can only overwrite files that are backed by the page cache, therefore an attacker cannot use CVE-2022-0847 to write to special files such as device files and/or pseudo file systems, which would facilitate container escapes (for example, by escaping through the cgroups release_agent)

How can you remediate CVE-2022-0847?

We recommend upgrading the Linux kernel to one of the following versions 5.16.11, 5.15.25, 5.10.102, or later. In case it is not possible, we highly recommend patching the Linux kernel using this patch.

Distro	Vulnerable version	Fixed version
Ubuntu	20.04.2 and later	No patch yet
Debian	Bullseye 5.10.84-1	Bullseye 5.10.92-2 bookworm and sid 5.16.11-1
Red Hat	Not Affected*	No patch yet

Note that RHEL8 (which uses Linux kernel 4.18) is marked by Red Hat as affected, since the underlying issue of CVE-2022-0847 (missing initialization) has been present in the kernel since version 4.9. However – the only currently known vector for exploitation (the use of the PIPE_BUF_FLAG_CAN_MERGE) was introduced in version 5.8. As such Linux kernel versions between 4.9 and 5.7 could be exploited in the future through a different vector, but none of the current exploits work on these versions.

What mitigation options are available for CVE-2022-0847?

If upgrading or patching the kernel is not possible, you can deploy a seccomp profile that disallows the splice syscall. While this may cause issues in some software packages, blocking the syscall usually does not have an effect on legitimate applications, since use of this syscall is relatively rare.

Specifically, to protect Docker containers, it is possible to modify Docker’s default seccomp profile and remove splice from the list of allowed syscalls:

After creating the custom seccomp profile, it may be applied to a new Docker container by running:

docker run --security-opt seccomp=/path/to/seccomp/profile.json …

Stay up-to-date with JFrog Security Research

Follow the latest discoveries and technical updates from the JFrog Security Research team in our security research blog posts and on Twitter at @JFrogSecurity.

Find vulnerable versions with JFrog Xray

In addition to exposing new security vulnerabilities and threats, JFrog provides developers and security teams easy access to the latest relevant information for their software with automated security scanning by JFrog Xray SCA tool.