11–20 of 99 posts
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.
But glad you vented, I guess.
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.
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.
Why we settled on a file format that relies on invisible characters I'll never know.
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, JSON or TOML for things like configuration files. Nowadays there might be better alternatives, but YAML is the de facto standard.
It's also unfortunate that YAML got abused by people who wanted to turn it into a DSL, so we ended up with thousands of lines of Ansible playbooks, CI workflows, and Helm charts, but here we are.
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.
Why we settled on a file format that relies on invisible characters I'll never know.
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…
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…
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…
That description seems really unclear, like how can `Chart.lock` be a symlink to a `.bashrc`? Is the vulnerability that you ship a chart with `Chart.lock -> ../.bashrc`, and then helm writes to `Chart.lock`? Why is the fix specific to Chart.lock ( https://github.com/helm/helm/commit/76fdba4c8c2a4829a6b7abb4... ), wouldn't the fix be instead that "A chart cannot contain any symlinks outside of its root"?
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...
edit: ok actually it looks like the lockfile is special because it's the only instance of helm itself directly writing a file on behalf of a package consumer
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?
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.