@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.

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

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

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

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

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

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

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 :) )

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?

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.

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!

/label official-cve-feed

(Related to kubernetes/sig-security#1)

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'

@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