DirtyCred: Opening Pandora’s Box to Current and Future Container Escapes

October 10, 2022

| | Cloud & Application Security

What Is DirtyCred?

DirtyCred is a new Linux kernel exploitation technique that allows kernel Use After Free (UAF) or Double free vulnerabilities to swap a credential or file structure on the kernel heap memory to escalate privileges to root. The replaced credential or file structure provides root access on a Linux host and breaks out of the container at the same time. Ph.D. candidate Zhenpeng Lin and his team at Northwestern University found the new technique and presented the findings at Black Hat 2022 in August and released the exploit code last week.

Similarity to Dirty Pipe

The DirtyCred exploit is partly similar to the Dirty Pipe vulnerability (CVE-2022-0847) that was found in Linux pipes. Linux kernel exploit mitigation features like KASLR, SMEP, KPTI and others were easily bypassed due to the data-only nature of this exploit. Hence, Dirty Pipe worked on most of the Linux distros having kernel version 5.8+ at the time.
cnapp demo
Likewise, the DirtyCred exploit technique is kernel version-agnostic and universally works with any generic kernel. The only prerequisite for this technique is to have a reliable UAF or double free kernel bug. That makes this technique equally as powerful as Dirty Pipe.

DirtyCred Is an Exploit Technique — Not a Vulnerability

An important differentiation to understand is that DirtyCred is an exploit technique that takes advantage of weak design in the kernel to escalate privileges. It can be used in combination with any UAF or double free kernel vulnerability to escalate the privileges or break out of the container. This type of security issue is not easy to fix and requires kernel feature redesign. Moreover there are two approaches, the technique can either swap credentials on kernel heap memory by swapping the cred structure (part of task_struct) or it can swap credentials from a file on host using file structure . Both cases are equally powerful and can result in privilege escalation or container escape. An adversary requires only a reliable UAF bug in the kernel and they can develop a working exploit using this technique that can cause havoc.

Vulnerabilities Known to Be Exploited with DirtyCred

There are two known vulnerabilities shown to be exploited with DirtyCred by researchers. Both are UAF/double free flaws found in the Linux kernel — a requirement for this technique to work.
  1. CVE-2021-4154 is an UAF vulnerability found in Linux kernel's cgroup v1 parser. A local attacker with a user privilege could cause a privilege escalation by exploiting the fsconfig syscall parameter, leading to a container breakout and a denial of service on the system. The CVE-2021-4154 exploit code using the DirtyCred technique is publicly released here. Figure 1 shows successful privilege escalation on an Ubuntu host to overwrite the /etc/passwd file.
Figure 1. Successful exploitation of CVE-2021-4154 using DirtyCred
  1. CVE-2022-2588 is a double free vulnerability found in route4_change in the net/sched/cls_route.c filter implementation in the Linux kernel. This flaw allows a local user to crash the system and possibly lead to a local privilege escalation. CVE-2022-2588 is a new vulnerability for which exploit code or a proof of concept was published last week.
In the future, we expect more Linux kernel UAF or double free vulnerabilities using the DirtyCred technique to achieve privilege escalation and container escape, considering the relatively easy approach.

Exploit Mitigation

 

 

 

 

 

 

 

 

Artifacts of this exploit are extremely hard to detect due to the data-only nature of the exploit. Researchers suggested the use of vmalloc patch to separate privileged and unprivileged credentials on the heap (implications of using this patch are unknown at the time of the writing).

 

 As a defense-in-depth strategy, the following steps can be taken to harden your containerized environment and Linux hosts to protect from current and future zero-day exploits using DirtyCred.
  1. Upgrade the kernel version. When a critical kernel vulnerability like UAF/Double free is disclosed, it is paramount that available fixes are applied by upgrading the kernel version.
  2. Use non-root users to run your workload. Doing so acts as an additional layer of security where an attacker needs to work to get to the container root first before attempting to break out.
  3. Provide only required capabilities to the container. By limiting the capabilities of the container, the root account of the container becomes limited in its capabilities, which significantly reduces the chances of container escape. For example, to exploit the UAF bug CVE-2022-2588, the attacker needs CAP_NET_ADMIN. (Privileged containers have this capability — see Figure 4. The capability can be dropped if not in use.)
  4. Use seccomp profile. Docker default seccomp profiles protect against a number of dangerous system calls that can help attackers to break out of the container. Correct Seccomp profiles can help reduce the container attack surface significantly. For example, CVE-2021-4154 requires an unshare and fsconfig system call for a UAF bug to trigger. These system calls are blocked by the Docker default seccomp profile if enabled. Hence, the exploitation attempts fail (as shown in Figure 2) in the presence of a strong seccomp profile. Additionally, AppArmor and SELinux follow a mandatory access control (MAC)-based file system, which acts as an additional deterrent for attackers.
Figure 2. Unsuccessful exploitation when Docker default seccomp profile is applied
  1. Monitor host and containerized environment for a breach. In case a privileged workload or a host is compromised by attackers, the organization needs state-of-the-art monitoring and detection capabilities to prevent and detect advanced persistent threats (APTs), eCrime and nation-state actors. CrowdStrike can help with this. CrowdStrike Falcon® Cloud Security identifies any indicators of misconfiguration (IOMs) in your containerized environment to uncover a weakness. Falcon Cloud Security prevents and detects malicious activity on your host and containers to prevent and detect — in real time — breaches by eCrime and nation-state adversaries. Figures 3 and 4 show examples of misconfigured workloads that can be exploited by DirtyCred.
Figure 3. Workload without Docker seccomp profile
Figure 4. Privileged workload
With data collected by CrowdStrike, Figure 5 shows a workload without SELinux — one of the top 5 workload misconfigurations that can be exploited by DirtyCred. Additional network capabilities and CAP_SYS_ADMIN are also among the most common.
Figure 5. Top container misconfigurations
  1. Use CrowdStrike Falcon® Cloud Security Dynamic Container Analysis. Falcon Cloud Security Dynamic Container Analysis can analyze any or all of the container images to detect any suspicious activity including exploit attempts in detail. It tracks network, file system and other runtime activity in addition to vulnerabilities and misconfigurations in the image. Figure 6 shows the Falcon Cloud Security Dynamic Container Analysis report after a malicious image is run.
Figure 6. Dynamic Container Analysis report

Conclusion

DirtyCred is not a vulnerability — it’s a Kernel exploit technique that has reduced the attacker’s cost of zero-day exploit development in Linux. This means the attacker that finds the next Use After Free bug in Linux kernel will likely be able to escalate privileges and break out of the container, opening Pandora's box for container escapes. Due to the data-only nature of this exploit, it’s extremely difficult to detect artifacts of this exploit technique, but a containerized environment can use a defense-in-depth strategy to protect against current and future zero-days using DirtyCred. Hence, running the container workload with minimal privileges and monitoring the environment for signs of exploitation are absolute requirements for today’s escalating threat landscape. CrowdStrike Falcon® Cloud Security combines the power of agentless and agent-based protection by adopting “shift left” strategies to secure your environment from development to production, providing deeper visibility and security. They enable you to identify security gaps early in the development cycle and protect your environment runtime in production from any breach seeking to take advantage.

Additional Resources
Breaches Stop Here
Related Content
Shift Left, Measure Right: Assessing the Efficacy of Application Security in the Age of CI/CD
Shift Left, Measure Right: Assessing the Efficacy of Application Security in the Age of CI/CD
CrowdStrike Falcon Platform Supports Google Cloud's ARM-Based Axion CPUs
CrowdStrike Falcon Platform Supports Google Cloud's ARM-Based Axion CPUs
CrowdStrike Research Challenges Containerized Application Predictability Assumptions
CrowdStrike Research Challenges Containerized Application Predictability Assumptions