Helm Files.Lines Denial of Service via Empty Chart Files

Helm is a package manager for Charts for Kubernetes. From 4.0.0 to 4.1.3, Helm will install plugins missing provenance (.prov file) when signature verification is required. This vulnerability is fixed in 4.1.4.

Helm is a package manager for Charts for Kubernetes. From 4.0.0 to 4.1.3, a specially crafted Helm plugin, when installed or updated, will cause Helm to write the contents of the plugin to an arbitrary filesystem location. To prevent this, validate that the plugin.yaml of the Helm plugin does not include a version: field containing POSIX dot-dot path separators ie. "/../". This vulnerability is fixed in 4.1.4.

A Helm contributor discovered uninitialized variable vulnerability when Helm parses index and plugin yaml files missing expected content.

Impact

When either an index.yaml file or a plugins plugin.yaml file were missing all metadata a panic would occur in Helm.

In the Helm SDK this is found when using the LoadIndexFile or DownloadIndexFile functions in the repo package or the LoadDir function in the plugin package. For the Helm client this impacts functions around adding a repository and all Helm functions if a malicious plugin is added as Helm inspects all known plugins on each invocation.

Patches

This issue has been resolved in Helm v3.14.2.

Workarounds

If a malicious plugin has been added which is causing all Helm client commands to panic, the malicious plugin can be manually removed from the filesystem.

If using Helm SDK versions prior to 3.14.2, calls to affected functions can use recover to catch the panic.

For more information

Helm's security policy is spelled out in detail in our SECURITY document.

Credits

Disclosed by Jakub Ciolek at AlphaSense.

A Helm contributor discovered a path traversal vulnerability when Helm saves a chart including at download time.

Impact

When either the Helm client or SDK is used to save a chart whose name within the Chart.yaml file includes a relative path change, the chart would be saved outside its expected directory based on the changes in the relative path. The validation and linting did not detect the path changes in the name.

Patches

This issue has been resolved in Helm v3.14.1.

Workarounds

Check all charts used by Helm for path changes in their name as found in the Chart.yaml file. This includes dependencies.

Credits

Disclosed by Dominykas Blyžė at Nearform Ltd.

A Helm contributor discovered that a specially crafted Chart.yaml file along with a specially linked Chart.lock file can lead to local code execution when dependencies are updated.

Impact

Fields in a Chart.yaml file, that are carried over to a Chart.lock file when dependencies are updated and this file is written, can be crafted in a way that can cause execution if that same content were in a file that is executed (e.g., a bash.rc file or shell script). If the Chart.lock file is symlinked to one of these files updating dependencies will write the lock file content to the symlinked file. This can lead to unwanted execution. Helm warns of the symlinked file but did not stop execution due to symlinking.

This affects when dependencies are updated. When using the helm command this happens when helm dependency update is run. helm dependency build can write a lock file when one does not exist but this vector requires one to already exist. This affects the Helm SDK when the downloader Manager performs an update.

Patches

This issue has been resolved in Helm v3.18.4

Workarounds

Ensure the Chart.lock file in a chart is not a symlink prior to updating dependencies.

For more information

Helm's security policy is spelled out in detail in our SECURITY document.

Credits

Disclosed by Jakub Ciolek at AlphaSense.

Helm is a package manager for Charts for Kubernetes. Prior to 3.18.4, a specially crafted Chart.yaml file along with a specially linked Chart.lock file can lead to local code execution when dependencies are updated. Fields in a Chart.yaml file, that are carried over to a Chart.lock file when dependencies are updated and this file is written, can be crafted in a way that can cause execution if that same content were in a file that is executed (e.g., a bash.rc file or shell script). If the Chart.lock file is symlinked to one of these files updating dependencies will write the lock file content to the symlinked file. This can lead to unwanted execution. Helm warns of the symlinked file but did not stop execution due to symlinking. This issue has been resolved in Helm v3.18.4.

Helm Chart extraction output directory collapse via Chart.yaml name dot-segment

Helm is a package manager for Charts for Kubernetes. From 4.0.0 to 4.1.3, a specially crafted Helm plugin, when installed or updated, will cause Helm to write the contents of the plugin to an arbitrary filesystem location. To prevent this, validate that the plugin.yaml of the Helm plugin does not include a version: field containing POSIX dot-dot path separators ie. "/../". This vulnerability is fixed in 4.1.4.

A Helm contributor discovered that a specially crafted JSON Schema within a chart can lead to a stack overflow.

Impact A JSON Schema file within a chart can be crafted with a deeply nested chain of references, leading to parser recursion that can exceed the stack size limit and trigger a stack overflow.

Patches This issue has been resolved in Helm v3.17.3.

Workarounds Ensure that the JSON Schema within any charts loaded by Helm does not have a large number of nested references. These JSON Schema files are larger than 10 MiB.

For more information Helm's security policy is spelled out in detail in our SECURITY document.

Credits Disclosed by Jakub Ciolek at AlphaSense.

A Helm contributor discovered that a specially crafted chart archive file can cause Helm to use all available memory and have an out of memory (OOM) termination.

Impact A chart archive file can be crafted in a manner where it expands to be significantly larger uncompressed than compressed (e.g., >800x difference). When Helm loads this specially crafted chart, memory can be exhausted causing the application to terminate.

Patches This issue has been resolved in Helm v3.17.3.

Workarounds Ensure that any chart archive files being loaded by Helm do not contain files that are large enough to cause the Helm Client or SDK to use up available memory leading to a termination.

For more information Helm's security policy is spelled out in detail in our SECURITY document.

Credits Disclosed by Jakub Ciolek at AlphaSense.

A flaw was found in the helm package. The 'getHostByName' is a Helm template function introduced in Helm v3 and can accept a hostname and return an IP address for that hostname. To get the IP address, the function performs a DNS lookup. The DNS lookup happens when used with 'helm install|upgrade|template' or when the Helm SDK is used to render a chart. Information passed into the chart can be disclosed to the DNS servers used to look up the IP address. For example, a malicious chart could inject getHostByName into a chart to disclose values to a malicious DNS server.

A flaw was found in Helm, a tool for managing Charts, a pre-configured Kubernetes resources. Versions prior to 3.10.3 are subject to NULL Pointer Dereference in thechartutil package that could cause a segmentation violation. The chartutil package contains a parser that loads a JSON Schema validation files into structures Go can work with. Some schema files can cause array data structures to be created, causing a memory violation. Applications that use the chartutil package in the Helm SDK to parse a schema files may result in a denial of service.

A Helm contributor discovered that it was possible to craft a JSON Schema file in a manner which could cause Helm to use all available memory and have an out of memory (OOM) termination.

Impact A malicious chart can point $ref in values.schema.json to a device (e.g. /dev/) or other problem file which could cause Helm to use all available memory and have an out of memory (OOM) termination.

Patches This issue has been resolved in Helm v3.18.5.

Workarounds Make sure that all Helm charts that are being loaded into Helm doesn't have any reference of $ref pointing to /dev/zero.

References Helm's security policy is spelled out in detail in our SECURITY document.

Credits Disclosed by Jakub Ciolek at AlphaSense.

Helm is a package manager for Charts for Kubernetes. Prior to version 3.18.5, it is possible to craft a JSON Schema file in a manner which could cause Helm to use all available memory and have an out of memory (OOM) termination. This issue has been resolved in Helm 3.18.5. A workaround involves ensuring all Helm charts that are being loaded into Helm do not have any reference of $ref pointing to /dev/zero.

A Helm contributor discovered an improper validation of type error when parsing Chart.yaml and index.yaml files that can lead to a panic.

Impact

There are two areas of YAML validation that were impacted. First, when a Chart.yaml file had a null maintainer or the child or parent of a dependencies import-values could be parsed as something other than a string, helm lint would panic. Second, when an index.yaml had an empty entry in the list of chart versions Helm would panic on interactions with that repository.

Patches

This issue has been resolved in Helm v3.18.5.

Workarounds

Ensure YAML files are formatted as Helm expects prior to processing them with Helm.

References

Helm's security policy is spelled out in detail in our SECURITY document.

Credits

Disclosed by Jakub Ciolek at AlphaSense.

Helm is a package manager for Charts for Kubernetes. Prior to version 3.18.5, when parsing Chart.yaml and index.yaml files, an improper validation of type error can lead to a panic. This issue has been resolved in Helm 3.18.5. A workaround involves ensuring YAML files are formatted as Helm expects prior to processing them with Helm.

A flaw was found in Helm, a tool for managing Charts, a pre-configured Kubernetes resources. Versions prior to 3.10.3 are subject to Uncontrolled Resource Consumption. Input to functions in the strvals package could cause a stack overflow that is unrecoverable by Go. Applications that use functions from the strvals package in Helm SDK may result in a denial of service.

Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-56hp-xqp3-w2jf. This link is maintained to preserve external references.

Original Description Helm is a tool for managing Charts (packages of pre-configured Kubernetes resources). In versions of helm prior to 3.6.1, a vulnerability exists where the username and password credentials associated with a Helm repository could be passed on to another domain referenced by that Helm repository. This issue has been resolved in 3.6.1. There is a workaround through which one may check for improperly passed credentials. One may use a username and password for a Helm repository and may audit the Helm repository in order to check for another domain being used that could have received the credentials. In the index.yaml file for that repository, one may look for another domain in the urls list for the chart versions. If there is another domain found and that chart version was pulled or installed, the credentials would be passed on.

Withdrawn Advisory

This advisory has been withdrawn because the issue describes intended behavior and the output is not exposed to unauthorized users. This link has been maintained to preserve external references.

Original Description

An issue was discovered in Cloud Native Computing Foundation (CNCF) Helm. It displays values of secrets when the --dry-run flag is used. This is a security concern in some use cases, such as a --dry-run call by a CI/CD tool. NOTE: the vendor's position is that this behavior was introduced intentionally, and cannot be removed without breaking backwards compatibility (some users may be relying on these values).

Impact

During a security audit of Helm's code base, Helm maintainers identified a bug in which a Helm plugin can contain duplicates of the same entry, with the last one always used. If a plugin is compromised, this lowers the level of access that an attacker needs to modify a plugin's install hooks, causing a local execution attack.

To perform this attack, an attacker must have write access to the git repository or plugin archive (.tgz) while being downloaded (which can occur during a MITM attack on a non-SSL connection).

Patches

This issue has been patched in Helm 2.16.11 and Helm 3.3.2.

Workarounds

Make sure to install plugins using a secure connection protocol like SSL.

Fuzz testing, by Ada Logics and sponsored by the CNCF, identified input to functions in the strvals package that can cause an out of memory panic. Out of memory panics cannot be recovered from. Applications that use functions from the strvals package in the Helm SDK can have a Denial of Service attack when they use this package and it panics.

Impact

The strvals package contains a parser that turns strings into Go structures. For example, the Helm client has command line flags like --set, --set-string, and others that enable the user to pass in strings that are merged into the values. The strvals package converts these strings into structures Go can work with. Some string inputs can cause array data structures to be created causing an out of memory panic.

Applications that use the strvals package in the Helm SDK to parse user supplied input can suffer a Denial of Service when that input causes a panic that cannot be recovered from.

The Helm Client will panic with input to --set, --set-string, and other value setting flags that causes an out of memory panic. Helm is not a long running service so the panic will not affect future uses of the Helm client.

Patches

This issue has been resolved in 3.9.4.

Workarounds

SDK users can validate strings supplied by users won't create large arrays causing significant memory usage before passing them to the strvals functions.

For more information

Helm's security policy is spelled out in detail in our SECURITY document.

Credits

Disclosed by Ada Logics in a fuzzing audit sponsored by CNCF.

Flux2 is a tool for keeping Kubernetes clusters in sync with sources of configuration, and Flux's helm-controller is a Kubernetes operator that allows one to declaratively manage Helm chart releases. Helm controller is tightly integrated with the Helm SDK. A vulnerability found in the Helm SDK that affects flux2 v0.0.17 until v0.32.0 and helm-controller v0.0.4 until v0.23.0 allows for specific data inputs to cause high memory consumption. In some platforms, this could cause the controller to panic and stop processing reconciliations. In a shared cluster multi-tenancy environment, a tenant could create a HelmRelease that makes the controller panic, denying all other tenants from their Helm releases being reconciled. Patches are available in flux2 v0.32.0 and helm-controller v0.23.0.

A flaw was found in Helm. Applications that use the repo package in Helm SDK to parse an index file may suffer a denial of service when that input causes a panic that cannot be recovered from. The Helm Client will panic with an index file that causes a memory violation panic.

helm Before 2.7.2 is affected by: CWE-295: Improper Certificate Validation. The impact is: Unauthorized clients could connect to the server because self-signed client certs were aloowed. The component is: helm (many files updated, see https://github.com/helm/helm/pull/3152/files/1096813bf9a425e2aa4ac755b6c991b626dfab50). The attack vector is: A malicious client could connect to the server over the network. The fixed version is: 2.7.2.

Helm ChartMuseum version >=0.1.0 and < 0.8.1 contains a CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in HTTP API to save charts that can result in a specially crafted chart could be uploaded and saved outside the intended location. This attack appears to be exploitable via A POST request to the HTTP API can save a chart archive outside of the intended directory. If authentication is, optionally, enabled this requires an authorized user to do so. This vulnerability appears to have been fixed in 0.8.1.

All versions of Helm between Helm >=2.0.0 and < 2.12.2 contains a CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in The commands helm fetch --untar and helm lint some.tgz that can result when chart archive files are unpacked a file may be unpacked outside of the target directory. This attack appears to be exploitable via a victim must run a helm command on a specially crafted chart archive. This vulnerability appears to have been fixed in 2.12.2.

In Helm 2.x before 2.15.2, commands that deal with loading a chart as a directory or packaging a chart provide an opportunity for a maliciously designed chart to include sensitive content such as /etc/passwd, or to execute a denial of service (DoS) via a special file such as /dev/urandom, via symlinks. No version of Tiller is known to be impacted. This is a client-only issue.

Impact

During a security audit of Helm's code base, security researchers at Trail of Bits identified a bug in which the alias field on a Chart.yaml is not properly sanitized. This could lead to the injection of unwanted information into a chart.

Patches

This issue has been patched in Helm 3.3.2 and 2.16.11

Specific Go Packages Affected helm.sh/helm/v3/pkg/chartutil

Workarounds

Manually review the dependencies field of any untrusted chart, verifying that the alias field is either not used, or (if used) does not contain newlines or path characters.

Impact

During a security audit of Helm's code base, security researchers at Trail of Bits identified a bug in which the a Helm repository can contain duplicates of the same chart, with the last one always used. If a repository is compromised, this lowers the level of access that an attacker needs to inject a bad chart into a repository.

To perform this attack, an attacker must have write access to the index file (which can occur during a MITM attack on a non-SSL connection).

Specific Go Packages Affected helm.sh/helm/v3/pkg/repo

Patches

This issue has been patched in Helm 3.3.2 and 2.16.11

Workarounds

- do not install charts from repositories you do not trust - fetch charts using a secure channel of communication (such as TLS) - use helm pull to fetch the chart, then review the chart’s content (either manually, or with helm verify if it has been signed) to ensure it has not been tampered with - manually review the index file in the Helm repository cache before installing software.