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

41–50 of 99 posts

Re: Helm local code execution via a malicious chart

#41

Post by cluckindan »

mrheosuper wrote: post #16
imiric wrote: post #13

Earlier quoted context omitted.

You use invisible characters whenever you press Enter or Space. If you're referring to Tab, many of the most popular programming languages like Go and Python use them as part of their syntax. The reason YAML was popularized is because it was a response to XML which isn't user friendly to write. It's unfortunate that the spec got so convoluted, and uses a lot of implicit behavior, but I'd rather write YAML than XML, J…

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.

Re: Helm local code execution via a malicious chart

#42

Post by cluckindan »

qsort wrote: post #29
quotemstr wrote: post #19

But I thought security vulnerabilities couldn't happen in memory-safe languages!

But I thought accidents wouldn't happen if we wear helmets! Clearly they're worthless!

Sarcasm aside: wearing a helmet causes riders to take more risks, leading to more accidents.

https://www.sciencedirect.com/science/article/pii/S136984781...

I’d still wear one, but also try to be more careful knowing that the helmet provides a false sense of security.

I do believe the analogy holds very true with programming habits.

Re: Helm local code execution via a malicious chart

#44

Post by sofixa »

imiric wrote: post #13
ChocolateGod wrote: post #7

Earlier quoted context omitted.

Why we settled on a file format that relies on invisible characters I'll never know.

You use invisible characters whenever you press Enter or Space. If you're referring to Tab, many of the most popular programming languages like Go and Python use them as part of their syntax. The reason YAML was popularized is because it was a response to XML which isn't user friendly to write. It's unfortunate that the spec got so convoluted, and uses a lot of implicit behavior, but I'd rather write YAML than XML, J…

> many of the most popular programming languages like Go and Python use them as part of their syntax

Go doesn't use tabs or whitespace as a part of its syntax. It's a part of the formatting, but not the syntax of the language.

Python on the other hand, one extra tab or whitespace can cause havoc.

Re: Helm local code execution via a malicious chart

#46

Post by steveBK123 »

Joker_vD wrote: post #34
codebastard wrote: post #22

So the attack vector is: - You have access to my file system - You have access to the helm repository You place malicious binaries outside the helm directory. Helm will now execute malicious code through the helm chart pointing outside the helm directory. Don't I have already bigger problems if you have access to my file system to place there malicious code? Is the danger here that one can get an execute permission?…

Yeah, there is a rather strong "downloading and executing arbitrary code from the Internet may lead to execution of arbitrary code" kind of vibe there.

And yet you just described the behavior of many mid-size company "DevOps" departments.

Re: Helm local code execution via a malicious chart

#47

Post by xyst »

Pretty cool and nice find. I already have a "malicious" Chart.yaml in mind for this attack just based on the description of vuln.

Fortunately, my dotfiles are managed with nix so trying to write to those files on a read only partition will raise many red flags for me.

I don't use bash, but maybe should write a dummy .bashrc (and other start up script equivalents for fish) as some sort of canary.

If I happen to overlook the malicious shell script crafted in a dependency on helm chart, I would get nasty errors that a process was trying to write to a read only file.

Re: Helm local code execution via a malicious chart

#48

Post by captn3m0 »

Joker_vD wrote: post #34
codebastard wrote: post #22

So the attack vector is: - You have access to my file system - You have access to the helm repository You place malicious binaries outside the helm directory. Helm will now execute malicious code through the helm chart pointing outside the helm directory. Don't I have already bigger problems if you have access to my file system to place there malicious code? Is the danger here that one can get an execute permission?…

Yeah, there is a rather strong "downloading and executing arbitrary code from the Internet may lead to execution of arbitrary code" kind of vibe there.

Starting on the other side of the airtight hatchway: https://devblogs.microsoft.com/oldnewthing/20221004-00/?p=10...

Re: Helm local code execution via a malicious chart

#49

Post by mfer »

6LLvveMx2koXfwn wrote: post #25
yelirekim wrote: post #8

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

Having read the CVE multiple times I am still unsure how 2. above happens? Is it possible through the malicious chart itself or is it a dependency for the CVE to be in play at all? And if the latter - what local process would write a symlink from a helm lock file to any kind of system start up script which doesn't point to a much bigger problem than this CVE?

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.

Re: Helm local code execution via a malicious chart

#50

Post by mfer »

heisenbit wrote: post #17
yelirekim wrote: post #8

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

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.

Post reply on HN