A group of academics from Northwestern University has disclosed a new privilege escalation vulnerability dubbed “Dirty Cred” in the Linux Kernel. Researchers say that though the new exploitation is similar in impact as same as the 6-month-old privilege escalation vulnerability “Dirty Pipe,” however it is more universal in nature. We are here to let you know more about the Dirty Cred vulnerability, like how does it work and how you should protect your Linux Kernel from the vulnerability. Since it is more generic than any other Kernel permission bypass vulnerability, it is much required to know how does Dirty Cred vulnerability work and how you should protect your Linux Kernel from Dirty Cred vulnerability.
Table of Contents
Dirty Pipe vs Dirty Cred
If you remember “Dirty Pipe” (CVE-2022-0847), one of the serious privilege escalation vulnerabilities that made news headlines early in the year, which abuses the Linux kernel pipe mechanism to inject data to arbitrary files. Dirty Cred also has the capability to create the same impact as Dirty Pipe. Although Dirty Cred has the same impact, it is more generic and powerful than Dirty Pipe vulnerability. This is because, Dirty Pipe, as a vulnerability, doesn’t deal with kernel address randomization and pointer integrity check; moreover, a pipe-abusive power is required to exploit the Dirty Pipe vulnerability, which is harder to follow.
Well, in the case of Dirty Cred, it works with any vulnerabilities with double-free ability to demonstrate dirty-pipe-like ability. Additionally, it inherits all the kernel protections bypass capabilities and takes the Dirty Pipe like vulnerability to the next level that allows the ability to overwrite an arbitrary file to escalate privilege. Researchers also noted that Dirty Cred vulnerability is capable of escaping the container actively that dirty pipe is not capable of.
Despite all these, what makes Dirty Cred different then Dirty Pipe is that Dirty Pipe abuses the Linux Kernel mechanism to inject data into unprivileged arbitrary files. The same Dirty Cred also abuses the Linux Kernel credential permission mechanism to write data to unprivileged arbitrary files and run high privileged commands in root contests.
Summary of Dirty Cred Vulnerability – CVE-2022-2588
Dirty Cred is a local privilege escalation vulnerability that is capable of bypassing kernel credential permission checks such as Control Flow Integrity (CFI). The vulnerability has been tracked under the CVE ID CVE-2022-2588, with a CVSS score of 6.7 that enables attackers to perform privilege escalation by bypassing kernel credential permission checks.
The flaw lice in improper implementation of route4_change in the net/sched/cls_route.c filter in the Linux Kernel. The problem is due to the non-removal of an old filter from the hashtable before freeing it in some conditions. The flaw allows a local attacker to perform privilege escalation attacks and achieve further attacks like a denial of service, system crash, arbitrary code execution, and arbitrary command execution.
Important Points to Be Noted About the Dirty Cred Vulnerability:
- This is a local privilege escalation vulnerability, so advisories should have a local reach to the victim’s machine to exploit the flaw.
- It is able to bypass kernel credential permission checks like CFI using the flaw.
- The problem is due to the non-removal of an old filter from the hashtable before freeing it in some conditions.
- It allows attackers to perform a denial of service, system crash, arbitrary code execution, and arbitrary command execution attacks on the victim.
|Associated CVE ID||CVE-2022-2588|
|Description||A local privilege escalation vulnerability in the Linux Kernel|
|Associated ZDI ID||–|
|CVSS Score||6.7 Medium|
|Attack Vector (AV)||Local|
|Attack Complexity (AC)||Low|
|Privilege Required (PR||High|
|User Interaction (UI)||None|
Kernel Version Affected by the Dirty Cred Vulnerability – Cve-2022-2588
Since the flaw affects all versions of the Linux Kernel, it affects pretty much everything that is built on the Linux Kernel. At the time of publishing this article, no patches were rolled out by Kernel moderators since we are still in the early stage of the bug. We recommend doing a regular check-in kernel.org to see the latest updates on the release of the new Kernel version.
For more information about the affected Kernel versions, please visit your Linux distributions.
- RedHat: https://access.redhat.com/security/cve/cve-2022-2588
- Ubuntu: https://ubuntu.com/security/CVE-2022-2588
- Debian: https://security-tracker.debian.org/tracker/CVE-2022-2588
- SUSE: https://www.suse.com/security/cve/CVE-2022-2588.html
- Oracle Linux: https://linux.oracle.com/cve/CVE-2022-2588.html
How Does Dirty Cred Vulnerability Work?
To understand the Dirty Cred vulnerability, it is required to know about the Kernel Credential and User Permission System in Linux. Theoretically, Linux has 7 types of objects: Tasks, Files/inodes, Sockets, Message queues, Shared memory segments, Semaphores, and Keys. All these objects are associated with a set of credentials to define the ownership and access permission of these objects. The Dirty Cred vulnerability has been described using Task and File credentials.
List of Objects in Linux Kernel:
- Message queues
- Shared memory segments
The root problem with the Dirty Cred vulnerability is that it allows an attacker to swap their unprivileged credentials with privileged ones, which could be either task or file credentials. You can check out the BlackHat slides for detailed technical information.
In simple words, Linux Kernel allocates any tasks, no matter whether it is an unprivileged, privileged, legitimate, or illegitimate tasks, to a non-allocated free kernel heap memory for execution. What this bug offers to an attacker is it allows attackers to free up the memory of one of their unprivileged tasks and wait for a privileged task to fill up that memory.
Attackers need not wait for an administrator to perform a task on that attacker’s freed memory. Attackers can burst the memory utilization by trying to run thousands of their privileged tasks like su, mount, or sshd. Eventually, at some point in time, upon the completion of the cycle there, a time comes that allocate one of his privileged tasks will be allocated to the same memory that he freed up early. As soon as it happens, the attacker will be able to use the privileged task as a root user.
Time needed: 15 minutes
How Dirty Cred Vulnerability Works?
- Attacker running multiple unprivileged task on the Kernel Heap memory
Attacker running multiple unprivileged task on the Kernel Heap memory.
- Attacker uses a vulnerability like Dirty Pipe to freed up a memory of unprivileged task
Attacker uses a vulnerability like Dirty Pipe to freed up a memory of unprivileged task.
- Attacker freed up a unprivileged task with a vulnerability
Attacker freed up a unprivileged task from the kernel heap with a vulnerability like Dirty Pipe and wait until a privileged refills the memory.
- A privileged task has refilled in the freed memory
A privileged task has refilled in the freed memory was used by the attacker earlier.
The same applies to open file credentials as well.
- Basically, the attacker will write a file to memory with read-write (RDWR) permissions where he has access.
- Then the attacker will free the file object once the permission checks are done.
- Later the attacker will get a read-only (RDONLY) file to the same space freed in the second step.
- The attacker is going to get read-write (RDWR) access as the permission checks are done previously.
Note: Attackers do not need to wait for an administrator to write a file object to that attacker’s freed memory. The attacker can run scripts to reallocate a read-only file to that space.
Researchers have published a PoC on GitHub that describes this flaw. Followed by that, Mental Outlaw has published a video tutorial on his YouTube channel that shows how to test the Dirty Cred vulnerability on publicly hosted servers. If you want, you can play with it.
How to Protect Your Linux Kernel From Dirty Cred Vulnerability?
Since we are still in the early stage of the research work, it is yet to release the patch. Keep visiting the links we shared in this post to track an update about the fix.
Generally, security researchers have recommended isolating privileged credentials from unprivileged credentials in vmalloc to avoid cross cash attacks. However, there is no proper fix released to protect your Linux Kernel from Dirty Cred vulnerability at the time of writing this post.
There is a patched code that is made available on GitHub to patch the Dirty Cred flaw. If you want to implement it on your own, you can try it out.
We hope this post would help you know how does Dirty Cred vulnerability work and how should you protect your Linux Kernel from Dirty Cred vulnerability. Please share this post if you find this interested. Visit our social media page on Facebook, LinkedIn, Twitter, Telegram, Tumblr, Medium & Instagram, and subscribe to receive updates like this.