←back to thread

Helm local code execution via a malicious chart

(github.com)
171 points irke882 | 6 comments | 09 Jul 25 05:49 UTC | HN request time: 0s | source | bottom
Show context
yelirekim ◴[09 Jul 25 07:03 UTC] No.44507070[source]▶
The original vulnerability description is not worded very well, here's my understanding of what's going on:

1. Attacker crafts a malicious Chart.yaml containing arbitrary code

2. Replaces Chart.lock with a symlink pointing to a sensitive file (like .bashrc or other startup scripts)

3. When you run helm dependency update, Helm processes the malicious Chart.yaml and writes the payload to whatever file the symlink targets

4. Code executes when the targeted file is next used (e.g., opening a new shell)

Why This Works: Helm follows the symlink during the dependency update process without validating the target, allowing arbitrary file writes outside the intended chart directory.

replies(3): >>44507344 #>>44507626 #>>44508238 #
heisenbit ◴[09 Jul 25 07:57 UTC] No.44507344[source]▶
Can anyone explain in what setup an attacker who can create a symlink where Chart.lock was could not directly write .bashrc or similar? Is this related to how Git handles symlinks?
replies(3): >>44507386 #>>44508788 #>>44508988 #
mfer ◴[09 Jul 25 11:43 UTC] No.44508788[source]▶
This has nothing to do with Git. A symlink can be packaged up in a tarball and shipped from one system to another. An attacker would need to create a malicious Chart.yaml file and a Chart.lock file pointing to another file. Then ship those to a system where dependencies are then updated.

This doesn't affect things like installing or upgrading a chart. Dependencies aren't updated at that time.

replies(1): >>44510290 #
1. ajross ◴[09 Jul 25 14:12 UTC] No.44510290[source]▶
> A symlink can be packaged up in a tarball and shipped from one system to another.

True enough, but if you have a victim unpacking and building untrusted tarballs there's no security boundary being crossed, is there? You don't have to bother with this symlink nonsense, just update the install script to include your payload directly.

Honestly this vulnerability is dumb. I don't see any realistic scenario where it can be exploited by an unprivileged attacker.

replies(1): >>44511024 #
2. url00 ◴[09 Jul 25 15:13 UTC] No.44511024[source]▶
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.
replies(1): >>44511145 #
3. ajross ◴[09 Jul 25 15:21 UTC] No.44511145[source]▶
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.

replies(1): >>44515870 #
4. deathanatos ◴[09 Jul 25 23:47 UTC] No.44515870{3}[source]▶
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.)

replies(1): >>44516373 #
5. ajross ◴[10 Jul 25 01:33 UTC] No.44516373{4}[source]▶
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.
replies(1): >>44525179 #
6. deathanatos ◴[10 Jul 25 20:26 UTC] No.44525179{5}[source]▶
Yes? I don't find that that odd.

Certainly, it would be better to trust the upstream completely, but let's not kid ourselves? See the entire current state of software supply chain in the industry.

But when I visit a website, I don't expect the website to LCE me. Why should turning a YAML adlib into YAML LCE me, regardless of the trust of the upstream. This is not a privilege I'm expecting to give the upstream ever, and this behavior is a clear security bug, to me…