51–60 of 99 posts
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.
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.
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?
Git just moves symlinks across systems as is, so yes, you can use git to deploy the exploit.
Earlier quoted context omitted.
I think that there are "legitimate" use cases for symlinks that read from outside the root, which at this point are probably looked upon even less favorably. It's likely that making the change you're proposing would be backwards incompatible. I agree that it's not clearly explained why this isn't a concern though. A cursory search for other instances of os.WriteFile doesn't seem to surface any thorough controls... ed…
What use-case? If you have a chart that has `deploy.yaml` symlinked to `/home/john/testcharts/redis/deploy.yaml`, that chart is clearly not going to work on anyone's machine except john's, so that chart is useless on anyone else's machine. If you're saying the use-case is for charts that aren't distributed, well, I'm saying we should ban all symlinks on distribution (downloading and unpacking a chart should fail if i…
i.e. you have 3 different charts that all depends on `cache`, `load balancer` and `database` charts and you want to only ever have 1 version deployed of those subcharts so you want the parent chart locks linked
Earlier quoted context omitted.
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.
This is almost becoming a joke at this point, "assuming an attacker has access to the system, they can change things on the system".
If we're being honest, YAML is one of the dumbest ideas of the last 20 years to have proliferated. How we got from XML to here I cannot comprehend. This is not the first RCE involving YAML and it won't be the last.
NIH syndrome and "inverse second system effect". In the real second system effect, the second system is more complicated because it includes everything that could possibly be perceived as missing in the first system. In the inverse second system effect the first system was perceived as too complicated, not too simple, so the second system is much simpler and doesn't do its job well. Also this vuln has nothing to do w…
If we're being honest, YAML is one of the dumbest ideas of the last 20 years to have proliferated. How we got from XML to here I cannot comprehend. This is not the first RCE involving YAML and it won't be the last.
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 spaces for (n)indent ;)
Earlier quoted context omitted.
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.
> this systematic review found little to no support for the hypothesis bicycle helmet use is associated with engaging in risky behaviour.
What is the attack scenario here? Where are the security boundaries? How does the attacker gets their repository with a symlink in it to the victim? Is Helm typically run as a privileged user? How would this work? And why doesn't the vulnerability description give answers to these questions?
Basic tech news?
Capitalist news?
Vulture Capitalist news?