Dirty Pipe Linux Vulnerability: Overwriting Files in Container Images

The "Dirty Pipe" vulnerability (CVE-2022-0847) allows attackers to overwrite files within container images from inside a container, posing a significant threat to containerized environments. The attack begins with the adversary gaining access to a container, potentially through valid cloud accounts. Once inside, the attacker exploits the Dirty Pipe vulnerability to escalate privileges and modify files that should be read-only, such as configuration files shared across multiple containers. This is where BlueRock's Read-Only File Protection mechanism comes into play. By enforcing strict read-only policies on critical files and directories, BlueRock effectively prevents unauthorized modifications, ensuring that even if an attacker gains access to a container, they cannot alter the underlying image files. This protection is crucial in maintaining the integrity of containerized applications and preventing the spread of malicious changes across multiple containers.

• T1078.004: Valid Accounts: Cloud Accounts: The article describes how attackers can use the Dirty Pipe vulnerability (CVE-2022-0847) to overwrite files in container images from within a container. This implies that attackers can gain control of a container to execute this exploit. The first step in this attack scenario is the adversary gaining initial access to the container.
• T1068: Exploitation for Privilege Escalation: Once the attacker has access to the container, they utilize the Dirty Pipe vulnerability to modify files that should be read-only. This action is directly manipulating and altering the system's files to achieve their goal, which falls under the category of exploiting a privilege escalation vulnerability.
• T1105: Ingress Tool Transfer: The article mentions that the attacker can modify files from the underlying image, affecting all containers using that shared image. This action of modifying files in a way that affects multiple containers aligns with the technique of Ingress Tool Transfer, where the attacker transfers tools or files into the container to facilitate the attack.
• T1592.003: Gather Victim Host Information: Firmware: The attack's ability to modify configuration files such as nginx.conf to affect multiple running containers demonstrates the attacker’s ability to modify system configurations to maintain persistence or further their goals. This aligns with the concept of modifying system configurations.
• T1070.006: Indicator Removal: Timestomp: Finally, the article advises patching the Linux kernel to mitigate the vulnerability. This suggests that the persistence of the vulnerability can be mitigated by updating the system, highlighting the importance of applying security patches.

F1: An attacker leverages CVE-2022-0847 (Dirty Pipe) from within a compromised container to modify files in a shared, read-only base image layer, affecting other current and future containers using the same image on the host.

• Attacker gains initial access to execute code within a single container running on the target host. (Cited from: "To exploit this issue, attackers must have access to a single container on the host.")
  • BR-47: Container Capability Control - This mechanism is applicable because it allows restricting capabilities granted to containers. If the initial access vector or subsequent exploit execution relies on specific Linux capabilities that are removed by this policy, the attack could be hindered or blocked.
  • BR-67: Container Root User Control - This mechanism is applicable because it prevents non-init processes from running as root within a container. If the attacker gains access as a non-root user and the exploit requires root privileges within the container (and the compromised process is not PID 1), this mechanism would block the execution attempt.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable because it uses NSJail sandboxing to restrict process execution based on predefined rules. If the initial access involves starting an unauthorized process, or if the exploit execution requires process behaviors disallowed by the sandbox, this mechanism could block the attempt. (Status: 3: Roadmap)
• The host system is running a Linux kernel version 5.8 or later, which is vulnerable to CVE-2022-0847 (Dirty Pipe). (Cited from: "affected systems — those running Linux kernel 5.8 or above", "CVE-2022-0847, aka “Dirty Pipe”")
• Attacker identifies a target file within the container's underlying image layers that the container user has read permissions for, but normally cannot write to due to the overlay filesystem's copy-on-write mechanism. (Cited from: "overwrite the contents of files that they can read but shouldn’t be able to write to", "modify files from container images on the host, from inside a container", "When a user inside a container modifies a file from the underlying image, the original file should be copied... The original file should remain unmodified.")
• Attacker introduces and executes the Dirty Pipe exploit code within the compromised container, targeting the identified file. (Cited from: "Using the exploit provided by Max Kellermann in his blog...", "We’ll then copy in our exploit code...", "run our exploit, attempting to add a string... to the top of the file.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it prevents the execution of any new executable binaries or scripts not present in the original container image. If the attacker introduces the Dirty Pipe exploit code as a new file, this mechanism would block its execution.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it restricts process execution to allowed filesystem paths. If the attacker places the exploit code in a path not on the allowlist (e.g., /tmp), this mechanism would block its execution. (Status: 4: Idea)
  • BR-90: Process Exec Deny - This mechanism is applicable because it blocks process execution based on a deny list (e.g., specific names like 'dirtypipe-exploit'). If the exploit binary matches a denied pattern, its execution would be blocked. (Status: 4: Idea)
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable because it uses NSJail sandboxing. If the execution of the exploit process violates the sandbox rules, it could be blocked. (Status: 3: Roadmap)
• The exploit successfully overwrites the content of the target file directly within the shared, read-only image layer on the host filesystem, bypassing the standard copy-on-write behavior. (Cited from: "vulnerability that allows users on a Linux system to overwrite the contents of files that they can read but shouldn’t be able to write to.", "it was possible to modify files from container images on the host, from inside a container")
  • BR-25: Read-Only File Protection - This mechanism is directly applicable because it specifically detects and prevents unauthorized write attempts via pipes to files marked as read-only, which is the core technique used by the Dirty Pipe exploit.
  • BR-46: DirtyCred Protection - This mechanism is applicable because it monitors file permission hooks and deeper kernel paths to detect unauthorized write attempts to read-only files, similar to the conditions exploited by Dirty Pipe, potentially providing another layer of detection/prevention.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if the target file resides within a directory configured as critical by policy. It blocks any write attempts (regardless of process trust level) to files within these directories.
• The modification instantly affects other running containers on the same host that are based on the same image and are still referencing the original, unmodified file from the shared layer. (Cited from: "if you had a host with 10 nginx containers using a shared image, and the attacker modified the nginx.conf file in one, it would instantly change the files in the others, too, as long as they were still using the file from the underlying image.")
• New containers subsequently started on the host using the same poisoned base image will also contain the attacker-modified file. (Cited from: "poison an image on a host so that new containers would receive modified files.", "Now we go back to the host and start a new container, based on the same image... And we can clearly see our modified file")

​

F2: An attacker exploits CVE-2022-0847 (Dirty Pipe) from within a container to modify files on the host system that are mounted into the container as read-only volumes.

• Attacker gains initial access to execute code within a single container running on the target host. (Cited from: "To exploit this issue, attackers must have access to a single container on the host.")
  • BR-47: Container Capability Control - This mechanism is applicable because it allows restricting capabilities granted to containers. If the initial access vector or subsequent exploit execution relies on specific Linux capabilities that are removed by this policy, the attack could be hindered or blocked.
  • BR-67: Container Root User Control - This mechanism is applicable because it prevents non-init processes from running as root within a container. If the attacker gains access as a non-root user and the exploit requires root privileges within the container (and the compromised process is not PID 1), this mechanism would block the execution attempt.
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable because it uses NSJail sandboxing to restrict process execution based on predefined rules. If the initial access involves starting an unauthorized process, or if the exploit execution requires process behaviors disallowed by the sandbox, this mechanism could block the attempt. (Status: 3: Roadmap)
• The host system is running a Linux kernel version 5.8 or later, vulnerable to CVE-2022-0847. (Cited from: "affected systems — those running Linux kernel 5.8 or above", "CVE-2022-0847, aka “Dirty Pipe”")
• A volume or bind mount exists, mounting a part of the host's filesystem into the container with read-only permissions. (Cited from: "Another scenario for this exploit is one in which volumes are mounted from the host as read only")
  • BR-66: Host FS Mount Control - This mechanism is applicable because it enforces an allow list for host file system mounts within containers. If the specific host path being mounted read-only is not on the configured allow list, this mechanism would prevent the mount from being established in the first place. (Status: 3: Roadmap)
• Attacker identifies a target file within the read-only mounted volume for which the container user has read permissions. (Cited from: "overwrite the contents of files that they can read", "attackers can use this exploit to override that restriction")
• Attacker executes the Dirty Pipe exploit code within the compromised container, targeting the file within the read-only mount. (Cited from: "attackers can use this exploit")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it prevents the execution of any new executable binaries or scripts not present in the original container image. If the attacker introduces the Dirty Pipe exploit code as a new file within the container, this mechanism would block its execution.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it restricts process execution to allowed filesystem paths within the container. If the attacker places the exploit code in a path not on the allowlist (e.g., /tmp), this mechanism would block its execution. (Status: 4: Idea)
  • BR-90: Process Exec Deny - This mechanism is applicable because it blocks process execution based on a deny list (e.g., specific names like 'dirtypipe-exploit'). If the exploit binary matches a denied pattern, its execution would be blocked. (Status: 4: Idea)
  • BR-82: Process Runtime Execution Guardrails - This mechanism is applicable because it uses NSJail sandboxing. If the execution of the exploit process violates the sandbox rules, it could be blocked. (Status: 3: Roadmap)
• The exploit successfully overwrites the content of the target file on the host filesystem by leveraging the vulnerability through the read-only mount point, effectively bypassing the mount restriction. (Cited from: "overwrite the contents of files that they can read but shouldn’t be able to write to.", "override that restriction")
  • BR-25: Read-Only File Protection - This mechanism is directly applicable because it detects and prevents unauthorized write attempts via pipes to files marked as read-only, even when accessed through a mount point from within a container.
  • BR-46: DirtyCred Protection - This mechanism is applicable because it monitors for unauthorized write attempts to read-only files, which is the method used by Dirty Pipe, providing potential detection/prevention.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable if the target file on the host resides within a directory configured as critical by policy. It blocks any write attempts to files within these directories from any process, including those originating from a container.
  • BR-78: Host Setuid File Protection - This mechanism is applicable if the target file on the host filesystem is a setuid file owned by the host root. It specifically prevents containers from writing to such files.
• The file modification on the host persists and may affect the host system or other entities relying on the original content of that file.