Comment by heisenbit
5 days ago
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?
5 days ago
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?
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.
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
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.
> 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.
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.
4 replies →
Helm is a program that allows users to creates packages which other users consume. Those packages contain files that are normally generated by Helm itself, but apparently if you alter your package definition by hand you can replace Chart.lock with a symlink.
As I'm typing this it's occurring to me that you probably shouldn't be able to do that. The fix they applied was to prevent the actual write from occurring when trying to write the lockfile and determining that the lockfile is a symlink. They could (should?) also validate that like, the package itself hasn't been screwed with in this manner.