Summary
On January 31st 2024, Snyk announced the discovery of four vulnerabilities in Kubernetes and Docker.
- CVE-2024-21626: CVSS – High, 8.6
- CVE-2024-23651: CVSS – High, 8.7
- CVE-2024-23652: CVSS – Critical, 10
- CVE-2024-23653: CVSS – Critical, 9.8
For Kubernetes, the vulnerabilities are specific to the runc CRI. Successful exploitation allows an attacker to escape the container and gain access to the host operating system. To exploit these vulnerabilities, an attacker will need to control the Dockerfile when the containers are built.
All four vulnerabilities involve specially crafted Dockerfiles that cause race conditions to allow commands to run in an unexpected order. In this post, we will discuss each issue briefly and provide Falco rules to detect if adversaries exploit the above CVEs.
CVE-2024-21626
This vulnerability involves a flaw in the way the WORKDIR command is processed. When the Dockerfile is built and when the container is run, the WORKDIR command is executed before the file descriptors are actually closed. It’s possible to add a folder to keep access to the file descriptor even when closed. If the attacker intercepts the file descriptor related to the /sys/fs/ group, they’ll be able to create files directly on the host.
The following Falco rule will detect the affected container runtimes trying to change the directory to a proc file descriptor, which isn’t normal activity. This rule should be considered experimental and can be used in OSS Falco and Sysdig Secure as a custom rule.
- rule: Suspicious Chdir Event Detected
desc: Detects a process changing a directory using a proc-based file descriptor.
condition: >
evt.type=chdir and evt.dir=< and evt.rawres=0 and evt.arg.path startswith "/proc/self/fd/"
output: >
Suspicious Chdir event detected, executed by process %proc.name with cmdline %proc.cmdline under user %user.name (details=%evt.args proc.cmdline=%proc.cmdline evt.type=%evt.type evt.res=%evt.res fd=%evt.arg.fd nstype=%evt.arg.nstype proc.pid=%proc.pid proc.cwd=%proc.cwd proc.pname=%proc.pname proc.ppid=%proc.ppid proc.pcmdline=%proc.pcmdline proc.sid=%proc.sid proc.exepath=%proc.exepath user.name=%user.name user.loginuid=%user.loginuid user.uid=%user.uid user.loginname=%user.loginname group.gid=%group.gid group.name=%group.name container.id=%container.id container_name=%container.name image=%container.image.repository:%container.image.tag)
priority: WARNING
tags: [host, container]CVE-2024-23651
This CVE impacts Docker at build time by abusing mount and symlink commands to cause a race condition. More specifically, this class of vulnerability is called Time of Check Time of Use (TOCTOU). When Docker checks a value for sanity or security, some time passes before that value is used, the time in between is where an attacker can change the state.
Successful exploitation will grant an attacker write access to the underlying host OS. They can later launch malicious commands on the host via multiple methods – commonly seen as modified cron entries. The Create Symlink Over Sensitive Files Falco rule below can be used to detect successful exploitation of this vulnerability.
CVE-2024-23652
This Docker vulnerability is exploited during the build stage of a container by abusing the RUN command to trigger race conditions when doing a mount and symlink. The result of exploiting this issue can allow an attacker to delete an arbitrary file on the host OS. While this exploit may not provide additional access, it could allow for a denial of service (DoS) attack by deleting critical system files.
Falco can detect exploitation of CVE-2024-23651 and CVE-2024-23652 by looking for the CRI creating symlinks to sensitive locations on the host OS. The following Falco rule triggers an event if threat actors exploit the vulnerability by creating a symlink to a sensitive directory on the host OS. The Falco rule below is available in OSS Falco and Sysdig Secure.
- macro: create_symlink
condition: evt.type in (symlink, symlinkat) and evt.dir=<
- list: sensitive_file_names
items: [/etc/shadow, /etc/sudoers, /etc/pam.conf, /etc/security/pwquality.conf]
- list: sensitive_directory_names
items: [/, /etc, /etc/, /root, /root/]
- rule: Create Symlink Over Sensitive Files
desc: Detect symlink created over sensitive files
condition: >
create_symlink and
(evt.arg.target in (sensitive_file_names) or evt.arg.target in (sensitive_directory_names) or evt.arg.target contains "/var/spool/cron" or evt.arg.target contains "/var/cron" or evt.arg.target contains "/etc/cron" or evt.arg.target contains "/etc/security" or evt.arg.target contains "/usr/lib/cron")
output: >
Symlinks created over sensitive files by process %proc.name with parent %proc.pname under user %user.name with cmdline %proc.cmdline executed on %container.name (user.name=%user.name user.loginuid=%user.loginuid proc.cmdline=%proc.cmdline target=%evt.arg.target linkpath=%evt.arg.linkpath evt.type=%evt.type evt.res=%evt.res proc.name=%proc.name proc.pname=%proc.pname proc.pid=%proc.pid proc.cwd=%proc.cwd proc.ppid=%proc.ppid proc.pcmdline=%proc.pcmdline user.uid=%user.uid user.loginname=%user.loginname container.id=%container.id container.name=%container.name image=%container.image.repository:%container.image.tag)
priority: WARNING
tags: [host,container]CVE-2024-23653
This vulnerability allows an attacker to start a container as Privileged. This occurs due to an issue in Buildkit’s validation routines at container build time. If an attacker alters the Dockerfile to add a custom Buildkit LLB directive to the Dockerfile, they can cause it to bypass certain security checks that would have prevented it from obtaining privileged access. Once an attacker is inside a privileged container, they can easily escape to the host OS by a variety of methods.
CVE-2024-23653 can be detected by monitoring any privileged container being launched in your environment. Trusted images should be allow-listed, which makes any outliers immediately apparent. The Falco rule below is available in OSS Falco and Sysdig Secure.
- macro: container
condition: (container.id != host)
- macro: container_started
condition: >
((evt.type = container or
(spawned_process and proc.vpid=1)) and
container.image.repository != incomplete)
- rule: Launch Privileged Container
desc: Detect the initial process started in a privileged container. Exceptions are made for known trusted images.
condition: >
container_started and container and container.privileged=true
output: Privileged container %container.name with image %container.image.repository started (user.name=%user.name user.loginuid=%user.loginuid proc.cmdline=%proc.cmdline %container.info evt.type=%evt.type evt.res=%evt.res proc.pid=%proc.pid proc.cwd=%proc.cwd proc.ppid=%proc.ppid proc.pcmdline=%proc.pcmdline proc.sid=%proc.sid proc.exepath=%proc.exepath user.uid=%user.uid user.loginname=%user.loginname group.gid=%group.gid group.name=%group.name container.id=%container.id container.name=%container.name image=%container.image.repository:%container.image.tag)
priority: WARNING
tags: [container]Secure your cloud today with end-to-end detection
At the heart of Sysdig Secure lies Falco’s unified detection engine. This cutting‑edge engine leverages real‑time behavioral insights and threat intelligence to continuously monitor the multi‑layered infrastructure, identifying potential security breaches. Whether it’s anomalous container activities, unauthorized access attempts, supply chain vulnerabilities, or identity‑based threats, Sysdig ensures that organizations have a unified and proactive defense against evolving threats.
Dig deeper into how Sysdig provides continuous cloud security across AWS, GCP, and Azure.
Conclusion
The four vulnerabilities discovered by Snyk could enable supply chain attacks against Docker and Kubernetes.
If an attacker gains access to the Dockerfile, either through public or private repositories, they can exploit these vulnerabilities to either gain write access to the host OS or cause a denial of service against the host itself. Users, especially Developers, could be a target since Docker is a vulnerable application that may give attackers access to their workstations and gain a foothold on your network.
We recommend upgrading your Docker and Kubernetes software as quickly as possible due to their high severity. While vulnerability management is ongoing, the Falco rules provided in this article can provide detection in case any of the vulnerabilities are exploited.
The post Detecting ‘Leaky Vessels’ Exploitation in Docker and Kubernetes appeared first on Sysdig.