CVE-2021-25741: Symlink Exchange Can Allow Host Filesystem Access

[cjcullen]

A security issue was discovered in Kubernetes where a user may be able to create a container with subpath volume mounts to access files & directories outside of the volume, including on the host filesystem.

This issue has been rated High (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), and assigned CVE-2021-25741.

Affected Components and Configurations

This bug affects kubelet.

Environments where cluster administrators have restricted the ability to create hostPath mounts are the most seriously affected. Exploitation allows hostPath-like access without use of the hostPath feature, thus bypassing the restriction.

In a default Kubernetes environment, exploitation could be used to obscure misuse of already-granted privileges.

Affected Versions

v1.22.0 - v1.22.1

v1.21.0 - v1.21.4

v1.20.0 - v1.20.10

<= v1.19.14

Fixed Versions

This issue is fixed in the following versions:

v1.22.2

v1.21.5

v1.20.11

v1.19.15

Mitigation

To mitigate this vulnerability without upgrading kubelet, you can disable the VolumeSubpath feature gate on kubelet and kube-apiserver, and remove any existing Pods making use of the feature.

You can also use admission control to prevent less-trusted users from running containers as root to reduce the impact of successful exploitation.

Detection

If you find evidence that this vulnerability has been exploited, please contact security@kubernetes.io

Additional Details

See Kubernetes Issue #104980 for more details.

Acknowledgements

This vulnerability was reported by Fabricio Voznika and Mark Wolters of Google.

Thanks as well to Ian Coldwater, Duffie Cooley, Brad Geesaman, and Rory McCune for the thorough security research that led to the discovery of this vulnerability.

[k8s-ci-robot]

@cjcullen: The label(s) triage//lifecycle, triage/frozen, triage//area, triage/security, triage//kind, triage/bug, triage//committee, triage/security-response cannot be applied, because the repository doesn't have them.

In response to this:

/triage accepted /lifecycle frozen /area security /kind bug /committee security-response

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[san-coding]

Hey, is this issue still open? I would like to work on this, I am new to open source

[k8s-ci-robot]

@pacoxu: The label(s) committee/security-response cannot be applied, because the repository doesn't have them.

In response to this:

/triage accepted
/lifecycle frozen
/area security
/kind bug
/committee security-response

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[champtar]

I'm curious, was the fix for CVE-2017-1002101 incomplete ? (#60813 / https://kubernetes.io/blog/2018/04/04/fixing-subpath-volume-vulnerability/)

[skaven81]

Are there any notes regarding how to exploit this vulnerability, or is that embargoed until a fix is available?

[ghost]

Does the vulnerability still exists when using the "subPathExpr" field of container spec or just with the "subPath" field?

[YanzhaoLi]

Since v1.19.15 has already released. But I couldn't find which commit fix this issue: https://github.com/kubernetes/kubernetes/commits/v1.19.15

[champtar]

Fix is here #104253
When using VolumeSubpath feature, K8S mount the volume then bind mount the subpath and give that to the runtime. The source part of the mount (the subpath) is attacker controled, so we need to prevent symlink exchange attack. As the mount syscall take path and not file descriptor, we open the source path and check that it's in the volume, and we use /proc/<kubelet pid>/fd/<final fd>, a magic symlink that point to the open file/directory, thus closing the race condition.
The bug here is that K8S doesn't use the mount syscall directly but it uses the mount command, and the default behavior of utils-linux mount is to resolve symlink

-c, --no-canonicalize
              Don't canonicalize paths.  The mount command canonicalizes all paths (from  command
              line  or  fstab) by default. ...

so all the effort made to use /proc/<kubelet pid>/fd/<final fd> and confirm it's safe are reverted by utils-linux mount default behavior.
The fix is just to pass --no-canonicalize, really nice finding.
As all this happens before we call the runtime, we are still in the root mount namespace so we can mount over some directory, say /root/.ssh, so it's even a bit simpler than the runc CVE-2021-30465 exploit (shameless plug :) )

[etcshad0vv]

Hello @champtar, reading in your comment i am still not sure if this is not fixed by CVE-2017-1002101 which you already mentioned above,
looking into the solution key points:

Resolve all the symlinks in the subpath.
Starting with the base volume, open each path segment one by one, using the openat() syscall, and disallow symlinks. With each path segment, validate that the current path is within the base volume.

Did someone verify this CVE is exploitable?

[champtar]

Fix for CVE-2017-1002101 creates a safe path using /proc/x/fd/y trick and pass this safe magic symlink to the mount binary that resolves (canonicalize) the link before passing it to the mount syscall, allowing the race condition again. What was missed in 2017 (and that's easy to miss) is the util-linux mount default behavior, if k8s was using mount syscall directly the fix would have been good.

[etcshad0vv]

I couldn't really exploit it due to patching of CVE-2017-1002101 , if exploit is confirmed then it can be me not doing it properly!

[PushkarJ]

/label official-cve-feed

(Related to kubernetes/sig-security#1)

[mmeekah]

how do we update to fix version?

For example, I'm getting CVE-2021-25741 Security Vulnerability, the suggested fix version is :
"Upgrade to version v1.19.15,v1.20.11,v1.21.5,v1.22.1"

what commands do I run? Is it something like the below:

go get -u github.com/kubernetes/utils@v1.22.1

or go get -u k8s.io/utils@v1.22.1

I tied both, and the error says 'unknown revision 1.22.1'

[pcj]

@mmeekah you can just go get -u k8s.io/utils@latest, which will take the most recent of https://pkg.go.dev/k8s.io/utils?tab=versions