21 ms·

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 containin

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 targets 4. Code executes when the targeted file is next used (e.g., opening a new shell) Why This Works: Helm follows the symlink during the dependency update process without validating the target, allowing arbitrary file writes outside the intended chart directory.

heisenbit 1y 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?
- yelirekim 1y ago
  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.
- mfer 1y ago
  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.
  - ajross 1y ago
    > 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.
    - url00 1y ago
      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.
      - ajross 1y ago
        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.
        deathanatos 1y ago
        You're not installing the untrusted tarball; helm is merely supposed to be extracting it, and then rendering the templates contained within. (Those templates, once rendered, might then refer to pods, etc. that might be put into a k8s cluster (or perhaps we merely render then YAML, and never `apply` it), and in that sense, one might imagine that that is an install, but that's not the security boundary being crossed here; this would presumably result in execution on the host running helm, which would definitely be surprising.)
        ajross 1y ago
        You're quibbling over the meaning of "install" but apparently conceding the part about untrusted? OK, fair enough. I still argue that any process involving the extraction and (ahem) "rendering of contained templates" from untrusted sources is broken in ways a fix for this particular symlink issue isn't going to address.
- Tuna-Fish 1y ago
  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.
  - mdaniel 1y ago
    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
6LLvveMx2koXfwn 1y ago
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?
- mfer 1y ago
  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.
  - arp242 1y ago
    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".
    - stonemetal12 1y ago
      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.
    - yokaze 1y ago
      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.
brainzap 1y ago
thats funny because Helm refused to allow reference of external files (there is a github issue) but they follow symlinks xD

heisenbit 1y 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?

yelirekim 1y ago
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.
mfer 1y ago
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.
- ajross 1y ago
  > 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.
  - url00 1y ago
    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.
    - ajross 1y ago
      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.
      - deathanatos 1y ago
        You're not installing the untrusted tarball; helm is merely supposed to be extracting it, and then rendering the templates contained within. (Those templates, once rendered, might then refer to pods, etc. that might be put into a k8s cluster (or perhaps we merely render then YAML, and never `apply` it), and in that sense, one might imagine that that is an install, but that's not the security boundary being crossed here; this would presumably result in execution on the host running helm, which would definitely be surprising.)
        ajross 1y ago
        You're quibbling over the meaning of "install" but apparently conceding the part about untrusted? OK, fair enough. I still argue that any process involving the extraction and (ahem) "rendering of contained templates" from untrusted sources is broken in ways a fix for this particular symlink issue isn't going to address.
Tuna-Fish 1y ago
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.
- mdaniel 1y ago
  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

6LLvveMx2koXfwn 1y ago

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?

mfer 1y ago
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.
- arp242 1y ago
  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".
  - stonemetal12 1y ago
    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.
  - yokaze 1y ago
    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.

brainzap 1y ago

thats funny because Helm refused to allow reference of external files (there is a github issue) but they follow symlinks xD