Helm Files.Lines Denial of Service via Empty Chart Files

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.

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.

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.

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 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.

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 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.

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.

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 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 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 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.