Critical Kubernetes Vulnerabilities: Stay Informed

Wajahat Raja

September 27, 2023 - TuxCare expert team

In the ever-changing landscape of cybersecurity, vigilance is crucial, especially when it comes to complicated and frequently used systems like Kubernetes. A trio of high-severity security flaws have just been discovered, posing a substantial threat to Kubernetes environments. While these Kubernetes vulnerabilities primarily affect Windows endpoints within a Kubernetes cluster, their potential ramifications extend beyond Windows systems, emphasizing the significance of robust cross-platform safety measures in the Linux-centric world.

The CVE Trio: CVE-2023-3676, CVE-2023-3893, and CVE-2023-3955

The CVSS score for these three vulnerabilities, CVE-2023-3676, CVE-2023-3893, and CVE-2023-3955, is 8.8. They have the ability to execute remote code with elevated privileges within a Kubernetes cluster. Importantly, these flaws affect all Kubernetes systems involving Windows nodes.

Akamai responsibly disclosed these Kubernetes security risks on July 13, 2023, triggering a fast response from the Kubernetes community. On August 23, 2023, fixes were released, emphasizing the importance of collaborative efforts in the field of open-source software.

Unpacking the Kubernetes Vulnerabilities

The vulnerabilities are related to the manipulation of YAML files, a configuration language widely used in Kubernetes for managing container runtime security in applications. The possibility to exploit these flaws arises from the direct connection of YAML files and the Kubernetes engine.

Notably, YAML parsing vulnerabilities have already triggered red flags in Kubernetes security updates. CVE-2022-1471, for example, revealed a remote code execution vulnerability in the SnakeYaml parser, affecting the Kubernetes Java client. CVE-2021-25749 also permitted the inclusion of misspelled user names in YAML files, resulting in the execution of workloads with root.

The SubPath Subproperty Saga

The vulnerabilities we’re talking about today are inspired by earlier concerns with the “subPath” subproperty in YAML files. Using the “volume” property, Kubernetes allows the mounting of a directory from the host system inside a container, a capability commonly used in the Kubernetes ecosystem. This feature has numerous subproperties, “subPath” being one of them. When “subPath” is specified in a YAML file, it is processed by kubelet, a vital Kubernetes service.

PowerShell Intricacies

The root of these flaws is in how Kubernetes treats the “subPath” string. During processing, kubelet determines whether it is a symlink. This protection, on the other hand, is implemented via a PowerShell command invoked by the “exec.Command” function call. This opens the door for attackers to attach PowerShell code to the “subPath” string, which will then be executed.

PowerShell’s ability to assess values within strings before use allows attackers to easily introduce malicious commands. For example, an attacker may provide a YAML file with a “subPath” containing “$(Start-Process cmd)”. During path validation, kubelet will send this command to PowerShell, where it will be performed with the kubelet service’s privileges, specifically the SYSTEM level.

Expanding the Scope of CVE-2023-3676

The vulnerability underpinning this debate, CVE-2023-3676, was resolved in Kubernetes 1.28. The Kubernetes vulnerability assessment, however, resulted in the disclosure of two further command injection vulnerabilities: CVE-2023-3955 and CVE-2023-3893. While these weaknesses mostly affect Kubernetes on Windows in its
default setup, it is important to remember that attackers still need to gain application privileges on a node.

Kubernetes Exploit Prevention

To address these vulnerabilities, proactive steps are required. The DevSecOps for Kubernetes has chosen to remedy this class of flaws by switching from user-input-based parameters to environment variables. This change ensures that parameters are only processed as strings, preventing them from being evaluated as PowerShell expressions.

In context to Kubernetes patch management, administrators have options if immediate updates to the patched version are not possible. They can stop the use of “Volume.Subpath,” but this will have an impact on a regularly used feature and functionality. Another option is to use the Open Policy Agent (OPA), an open-source agent capable of carrying out policy-based activities. Administrators can write rules in OPA’s Rego language to prevent specific YAML files from being executed. Container image scanning can also be used to identify vulnerabilities.

Additionally, role-based access control (RBAC) should be used to limit the number of users who are authorized to conduct operations within a Kubernetes cluster. This comprehensive strategy improves security while reducing potential attack routes.

Conclusion

Vigilance and proactive security measures are critical in the Kubernetes world. While CVEs in Kubernetes (CVE-2023-3676, CVE-2023-3893, and CVE-2023-3955) mostly affect Windows endpoints within a Kubernetes cluster, the ramifications are widespread. Because Kubernetes clusters are interconnected, compromising a single node, even if it is running Windows, might have ramifications for the entire cluster’s configuration and security.

As we navigate the complex world of Kubernetes and its flaws, it becomes clear that Kubernetes best practices are essential, regardless of the platforms involved. It is not enough to defend one node in an ever-changing digital landscape; it is also necessary to preserve the Kubernetes cluster security.

The sources for this piece include articles in The Hacker News and CSO.

Summary