←back to thread

171 points irke882 | 2 comments | | HN request time: 0s | source
Show context
yelirekim ◴[] 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 ◴[] 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 #
1. Tuna-Fish ◴[] No.44508988[source]
A symlink is just a special file that contains a string of text, it's not tightly bound to the target like a hard link. You can write anything into that string of text, including, say, "~/.bashrc". Then you can ship that symlink onto another system, and it suddenly points to your .bashrc.

Git just moves symlinks across systems as is, so yes, you can use git to deploy the exploit.

replies(1): >>44510760 #
2. mdaniel ◴[] No.44510760[source]
As pedantry, to the very best of my knowledge symlinks could not contain "~" and have it mean $HOME - that's a shell-ism (or os.path.expanduser equivalent in your library). I was suspecting the attack vector may have used "/home/runner" or "/home/ubuntu" as very common paths that could exist and be writable by the user