CVE-2019-25210 was recently filed against the Helm project. This action was completed without engaging the Helm project and working through the documented security process and team. The Helm project was given no notice before the disclosure was released which resulted in the inability to provide an appropriate statement beforehand. This post serves as the response from the Helm project.

Not A Vulnerability In Helm​

The Helm project rejects this disclosure’s assertion of a vulnerability within Helm.

The advisory listing on GitHub lists the categorization as CWE-200, which is for “Exposure of Sensitive Information to an Unauthorized Actor”. The documentation for this CWE notes that its use is discouraged due to frequent misuse. The description aligns with the implementation within Helm in this situation.

The --dry-run flag, when used with helm install and helm upgrade, is designed to send all of the generated chart manifests to standard out that would normally be sent to the Kubernetes API. This is useful for multiple use cases, such as debugging the development of a chart (i.e. package). These manifests are generated from the chart logic. Kubernetes Secrets have been designed by the Kubernetes project to be manifests, like any other resource. When generating manifests, including Secrets, there are times they need to be debugged in order to ensure the generated structure is correct.

This functionality, used in many situations including local development environments, is not an issue. The output is not exposed to an unauthorized actor. In fact, the output is needed. If this functionality is used in an environment that captures the output for unauthorized actors, such as in a CI system, then the vulnerability is in the use of a tool that outputs this information, rather than in the tool itself.

Consider a simple alternative situation. There is a Kubernetes manifest file containing both secret and non-secret information. kubectl, the Kubernetes CLI, is used in an attempt to apply the manifest to a cluster and the attempt fails. So, the cat utility is used to display the contents of the file containing the Secret. Is it the vulnerability in cat for displaying the information or in the CI setup for using cat to display secret information? The vulnerability is in the use of the tool rather than the tool itself.

Helm Changes​

To provide greater clarity, the Helm maintainers have made two changes.

1. Documentation has been updated to make the possible exposure of secret information explicit.
2. A flag has been added, which will be available in the next minor release, that will hide secret information in the dry-run output of these commands.

Why A Delay In Response​

When the CVE listing was released and the Helm maintainers became aware, the team went to work evaluating the potential impacts.

The Helm project takes security seriously. Some examples of this include:

• A documented security policy that enables someone to contact the security team with encrypted communications.
• Two 3rd party security audits (on versions of Helm that contained this functionality).
• A fuzzing audit and continuous fuzzing has been set up.
• Documented security assurance case, which is an OpenSSF best practices requirement on the way to a silver level.
• Helm releases are signed by the maintainer who produced the release.

Normally, a discussion about a security issue would stay internal to the Helm project. But, this listing was public and contentious. Helm maintainers contacted security professionals from multiple organizations and sought feedback on the situation prior to publicly commenting or performing any remediation work.

The Helm security team is responsive. In this calendar year, there have been releases to address two CVEs responsibly reported. You can learn more about reporting security issues in the documented process and participate, when necessary, to keep the Helm project and community secure.