Kubernetes fixes Privilege Escalation Vulnerability
Share this:
Kubernetes has released a latest version that includes patches for security bugs that allow attackers to abuse the subPath property of YAML configuration files to execute malicious commands on Windows hosts.
The vulnerability allows remote code execution with SYSTEM privileges on all Windows endpoints within a Kubernetes cluster. To exploit this vulnerability, the attacker needs to apply a malicious YAML file on the cluster.
Kubernetes allows mounting a directory from the host system inside a container through a property called volume. This is a widely used feature and comes with several subproperties to define the path of the directory on the host and the mount path inside the container. The mountPath further has a subPath property that when provided in a YAML file is processed by kubelet, a core Kubernetes service.
It has been found that when the subPath string is processed, kubelet also checks if it is a symlink, which is part of the defenses put in place for the older vulnerabilities. However, it does this through a PowerShell command that is invoked by the “exec.Command” function call. This opens the possibility that an attacker could attach PowerShell code to the subPath string where it would be executed.
This vulnerability is now tracked as CVE-2023-3676 and was patched in Kubernetes 1.28, but it also led to the discovery and fixing of two more similar command injection vulnerabilities: CVE-2023-3955 and CVE-2023-3893. The flaw impacts Kubernetes on Windows in its default configuration, but the attacker needs to obtain apply privileges to a node.
The Kubernetes team chose to patch this class of vulnerabilities by passing parameters from environment variables instead of from user input which will be treated as strings — therefore, they will not be evaluated as expressions by PowerShell.
If they can’t update to the patched version immediately,
- Admins can disable the use of Volume.Subpath, but this will also cripple a commonly used feature and functionality.
- Use the Open Policy Agent (OPA), an open-source agent that can take policy-based actions based on the received data.
- Admins can create rules to block certain YAML files from being implemented using the Rego language in OPA,
- Use role-based access control (RBAC) to limit the number of users who can perform actions on a cluster.
