GHSA-56hp-xqp3-w2jf BIT-helm-2021-32690 CVE-2021-32690 GHSA-7jr6-prv4-5wf5 GO-2022-0384
Helm passes repository credentials to alternate domain
- Severity
- 6.8 / 10
- Medium · CVSS 3.1
- Exploit chance (EPSS)
- 1.43%
- Chance of exploitation in the next 30 days. Higher than 73.09% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-200 Exposure of Sensitive Information to an Unauthorized Actor
- Fix
3.6.1- Upgrade helm.sh/helm/v3 to this version or later
Description
While working on the Helm source, a Helm core maintainer discovered a situation where the username and password credentials associated with a Helm repository could be passed on to another domain referenced by that Helm repository.
Impact
The index.yaml within a Helm chart repository contains a reference where to get the chart archive for each version of a chart. The reference can be relative to the index.yaml file or a URL to location. The URL can point to any domain and this is a feature leveraged by Helm users. For example, an index.yaml file can be hosted on GitHub pages while the chart archives are hosted as GitHub releases. These are on different domain names and the index.yaml file points to the other domain.
When a username and password were associated with a Helm repository the username and password were also passed on to other domains referenced in the index.yaml file. This occurred when Helm went to retrieve a specific chart archive on the other domain.
Patches
This issue has been resolved in 3.6.1.
There is a slight behavior change to credential handling with regard to repositories. Usernames and passwords are only passed to the URL location of the Helm repository by default. The username and password are scoped to the scheme, host, and port of the Helm repository. To pass the username and password to other domains Helm may encounter when it goes to retrieve a chart, the new --pass-credentials flag can be used. This flag restores the old behavior for a single repository as an opt-in behavior.
Workarounds
If you use a username and password for a Helm repository you can 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, 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 have been passed on.
For more information
Helm's security policy is spelled out in detail in our SECURITY document.
Affected versions
Go
| Package | Vulnerable | Fixed in |
|---|---|---|
| helm.sh/helm/v3 | < 3.6.1 |
3.6.1 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
helm.sh/helm/v3 Go → 3.6.1
- go
go get helm.sh/helm/v3@v3.6.1 && go mod tidy
Severity breakdown
CVSS 3.1 6.8
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N
- Attack vector
- Network
- Attack complexity
- High
- Privileges required
- None
- User interaction
- None
- Scope
- Changed
- Confidentiality
- High
- Integrity
- None
- Availability
- None
Weakness
CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.
How to prevent it
- Architecture and Design: Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-hr2v-4r36-88hr Helm Chart extraction output directory collapse via `Chart.yaml` name dot-segment | Medium | Also affects helm.sh/helm/v3 |
| GHSA-f9f8-9pmf-xv68 Helm May Panic Due To Incorrect YAML Content | Medium | Also affects helm.sh/helm/v3 |
| GHSA-9h84-qmv7-982p Helm Charts with Specific JSON Schema Values Can Cause Memory Exhaustion | Medium | Also affects helm.sh/helm/v3 |
| GHSA-557j-xg8c-q2mm Helm vulnerable to Code Injection through malicious chart.yaml content | High | Also affects helm.sh/helm/v3 |
| GHSA-5xqw-8hwv-wg92 Helm Allows A Specially Crafted JSON Schema To Cause A Stack Overflow | Medium | Also affects helm.sh/helm/v3 |
| GHSA-4hfp-h4cw-hj8p Helm Allows A Specially Crafted Chart Archive To Cause Out Of Memory Termination | Medium | Also affects helm.sh/helm/v3 |
| GHSA-r53h-jv2g-vpx6 Helm's Missing YAML Content Leads To Panic | High | Also affects helm.sh/helm/v3 |
| GHSA-v53g-5gjp-272r Helm dependency management path traversal | Medium | Also affects helm.sh/helm/v3 |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor