Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Helm local code execution via a malicious chart

github.com

Post reply on HN
Print view View original

61–70 of 99 posts

Re: Helm local code execution via a malicious chart

#61

Post by stonemetal12 »

arp242 wrote: post #55
mfer wrote: post #49

Earlier quoted context omitted.

The attacker creates a symlink (e.g., using `ln -s`) to another file. The attacker needs to create the malicious Chart.yaml file and symlink that the Chart.lock file points to.

If being able to create files and symlinks to them is a pre-condition for this, then it's not a serious security bug. If you have that kind of access then there are a million nefarious things you can do. This is almost becoming a joke at this point, "assuming an attacker has access to the system, they can change things on the system".

It is on the level of "sudo curl URL". It is an obviously stupid thing to do from a security perspective, but projects have suggested doing it to install their software.

If you are new to helm or haven't considered the security around it, it is good to know what to look out for.

Re: Helm local code execution via a malicious chart

#62

Post by ajross »

mfer wrote: post #50
heisenbit wrote: post #17

Earlier quoted context omitted.

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?

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.

Re: Helm local code execution via a malicious chart

#63

Post by yokaze »

arp242 wrote: post #55
mfer wrote: post #49

Earlier quoted context omitted.

The attacker creates a symlink (e.g., using `ln -s`) to another file. The attacker needs to create the malicious Chart.yaml file and symlink that the Chart.lock file points to.

If being able to create files and symlinks to them is a pre-condition for this, then it's not a serious security bug. If you have that kind of access then there are a million nefarious things you can do. This is almost becoming a joke at this point, "assuming an attacker has access to the system, they can change things on the system".

I create a malicious chart or compromise one you use (with symlink to an arbitrary file and code).

You download charts either as a tarball from a helm repo or oci registry with helm and helm will create the files and links with your permissions, and send me whatever I wanted to extract from your system.

Yes, you should check things you download from the internet. But also, that is not how a chart is supposed to work.

Re: Helm local code execution via a malicious chart

#64

Post by baobun »

cluckindan wrote: post #41
mrheosuper wrote: post #16

Earlier quoted context omitted.

i always enjoy writting json more. I feel it's easier to translate/integrate json into the code.

YAML is a superset of JSON, so go right ahead and write your .yml files in JSON.

YAML is actually not a superset of JSON.

https://john-millikin.com/json-is-not-a-yaml-subset

https://news.ycombinator.com/item?id=30052633

Re: Helm local code execution via a malicious chart

#65

Post by empath75 »

arp242 wrote: post #55
mfer wrote: post #49

Earlier quoted context omitted.

The attacker creates a symlink (e.g., using `ln -s`) to another file. The attacker needs to create the malicious Chart.yaml file and symlink that the Chart.lock file points to.

If being able to create files and symlinks to them is a pre-condition for this, then it's not a serious security bug. If you have that kind of access then there are a million nefarious things you can do. This is almost becoming a joke at this point, "assuming an attacker has access to the system, they can change things on the system".

Helm is not intended to be able to write files outside of the directory you are rendering the templates to, and the directory that you have downloaded the chart to, so if there is a way to do that, it is a bug in the program and a security bug at that, particularly when the destination is controlled by someone who has written a malicious chart. That it also happens to be able to run arbitrary code makes it worse, but the primary problem is that it can write files outside of the chart directory or the directory you are rendering to at all.

This has nothing to do with whether you are running it in sudo or whatever. (and in fact on MacOs, I don't believe this requires running it with sudo permissions to overwrite ~/.zshrc for example)

Re: Helm local code execution via a malicious chart

#66

Post by mdaniel »

Tuna-Fish wrote: post #53
heisenbit wrote: post #17

Earlier quoted context omitted.

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

Re: Helm local code execution via a malicious chart

#68

Post by url00 »

ajross wrote: post #62
mfer wrote: post #50

Earlier quoted context omitted.

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…

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.

Re: Helm local code execution via a malicious chart

#69

Post by ajross »

url00 wrote: post #68
ajross wrote: post #62

Earlier quoted context omitted.

> 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…

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.

Re: Helm local code execution via a malicious chart

#70

Post by fao_ »

ivan4th wrote: post #58

Helm is an abomination, as the whole idea of using a text template engine to generate YAML is. And this vulnerability adds insult to injury ;) Sorry, just can't really recover from trauma of counting spaces and messing up newlines, etc. when writing Helm templates. You know, Lisp "sucks" because "you need to count parenthesis" (you actually don't), yet Helm is a widely accepted technology where you need to count spac…

Yeah, vi has supported % as "jump between matching parenthesis" since it's original release in the 1970s, and vim by default will do simple parenthesis matching and highlighting, I don't see why everyone is so scared of touching lisp for these reasons with modern editors (if your editor doesn't support either of the above... maybe it's not modern enough?)
Post reply on HN