Comment by url00
5 days ago
When you do a helm pull and download a chart from a repo, I believe it's a tar-ball. So if you have a workflow where you install charts from the filesystem you could be impacted. I've done that in the past.
5 days ago
When you do a helm pull and download a chart from a repo, I believe it's a tar-ball. So if you have a workflow where you install charts from the filesystem you could be impacted. I've done that in the past.
I can only repeat the assertion: if you have a victim pulling and installing untrusted tarballs, there is no security boundary being crossed.
It doesn't matter whether it's "from a repo". If you can't trust the repo it can feed you whatever it wants.
You're not installing the untrusted tarball; helm is merely supposed to be extracting it, and then rendering the templates contained within.
(Those templates, once rendered, might then refer to pods, etc. that might be put into a k8s cluster (or perhaps we merely render then YAML, and never `apply` it), and in that sense, one might imagine that that is an install, but that's not the security boundary being crossed here; this would presumably result in execution on the host running helm, which would definitely be surprising.)
You're quibbling over the meaning of "install" but apparently conceding the part about untrusted? OK, fair enough. I still argue that any process involving the extraction and (ahem) "rendering of contained templates" from untrusted sources is broken in ways a fix for this particular symlink issue isn't going to address.
1 reply →