Penetration Test Report (TrailOfBits): Helm Final Report 2020

Helm
Security Assessment
August 1 0, 2 020
Prepared For:
Matt Farina | H elm
matt@mattfarina.com
Matt Butcher | H elm
technosophos@gmail.com
Prepared By:
Dominik Czarnota | T rail of Bits
dominik.czarnota@trailofbits.com
Johanna Ratliff | T rail of Bits
johanna.ratliff@trailofbits.com
Executive Summary
Project Dashboard
Engagement Goals
Coverage
Recommendations Summary
Short term
Long term
Findings Summary
1. Helm does not warn the user about important file permissions that are too broad
2. The V alidName Kubernetes resource name regex may lead to denial of service
3. Helm's Mac OS build keeps a file descriptor to / etc/.mdns_ debug file open if this file
exists due to bug in m dns/lookup library
4. Lack of name validation in h elm create command allows data to be injected into
generated y aml files
5. The h elm create command does not overwrite files as stated in its help message
6. The h elm create command does not warn that a directory or file already exists
7. Helm executes VCS commands as external programs relying on user configuration
8. Plugins can't be installed from VCS if URL ends with archive extractor’s extension
9. Plugin command name is not validated; can duplicate other plugin commands and
Helm's top-level commands
10. The h elm dependency list command won't print correct dependency status for
certain dependency names
11. Path traversal through chart's dependency alias
12. Chart repository i ndex.yaml file allows for duplicate entries
13. Adding h elm repository may overwrite another one without warning
14. Directories created via o s.MkdirAll are not checked for permissions
A. Vulnerability Classifications
B. Code Quality Recommendations
C. The ValidName Regex Denial-of-Service Timing
D. How to Reproduce Finding 12 (Duplicate Entries in Chart Repository)
E. CNCF Requirements Criteria Review
© 2020 Trail of Bits Helm Assessment | 1
Executive Summary
From July 27 through August 5, 2020, Trail of Bits reviewed the security of Helm. We
conducted this assessment over the course of three person-weeks with two engineers
working from v 3.3.0-rc.1 ( c2dfaa) from the Helm repository.
In week one, we employed static analysis techniques such as g osec, e rrcheck, C odeQL,
semgrep, and the GoLand code inspection feature while gaining a deeper understanding of
the codebase through manual review. This yielded three findings ranging from
informational to low severity. Additionally, we investigated the potential issue of y aml
bombs, which resulted in pull request g o-yaml/yaml#637 to the g o-yaml library used by
Helm. This fix would address a theoretical scenario where the underlying counters used to
prevent y aml bombs could overflow and lead to a denial of service.
In the final week, we conducted deeper analysis of certain code paths such as Helm's
plugin system, template parsing and rendering, and interactions with Kubernetes clusters.
This resulted in 11 more findings ranging from informational to medium severity. Most
notably, findings T OB-HELM-009, T OB-HELM-011, and T OB-HELM-012 detail issues related
to plugin command duplication; a path traversal in a chart configuration file that can lead
to processing of malicious y aml files or information leaks; and a y aml validation deficiency
that allows duplicate entries in chart repository index files.
We also reviewed the CNCF requirements criteria in A ppendix E and included code quality
recommendations in A ppendix B to help improve and future-proof the Helm codebase.
Our assessment revealed a total of 14 findings ranging from medium to informational
severity. Overall, the Helm codebase maturity could be improved. In some areas, it does
not perform the necessary data validation, and in others the implementation either does
not match the expected functionality or is not fully documented. These gaps can affect the
security posture of the system since Helm users may make incorrect assumptions.
To improve the security posture of Helm, we recommend addressing the findings in this
report, prioritizing short-term recommendations, and integrating long-term
recommendations into future releases. Once fixes are applied, another assessment should
be performed to ensure the fixes are adequate and do not introduce additional security
risks.
© 2020 Trail of Bits Helm Assessment | 2
Project Dashboard
Application Summary
Name Helm
Version v3.3.0-rc.1 (c2dfaa)
Type Go
Platforms MacOS, Linux, Windows
Engagement Summary
Dates July 27, 2020–Aug 5, 2020
Method Whitebox
Consultants Engaged 2
Level of Effort 3 person-weeks
Vulnerability Summary
Total High-Severity Issues 0
◼◼◼
Total Medium-Severity Issues 3
◼◼◼◼◼◼◼
Total Low-Severity Issues 7
Total Informational-Severity Issues 3 ◼◼◼
Total Undetermined-Severity Issues 0
Total 13
Category Breakdown
◼
Access Controls 1
◼
Auditing and Logging 1
◼
Configuration 1
◼◼◼◼◼◼◼◼◼
Data Validation 9
◼
Undefined Behavior 1
Total 13
© 2020 Trail of Bits Helm Assessment | 3
Engagement Goals
The engagement was scoped to provide a security assessment of Helm 3. Specifically, we
sought to answer the following questions:
● Is the data processed by Helm validated properly?
● Are the filesystem permissions used by Helm secure?
● Does Helm provide the necessary logging for sensitive operations?
● Does Helm properly use basic cryptographic practices, where applicable?
● Are there any correctness issues in error-handling within Helm?
● Is there any evidence of credential issues or exposure?
● Does Helm meet CNCF requirements for secure development?
Coverage
Internal Helm logic and helm CLI. U sing automated analysis tools such as g osec,
ineffassign, e rrcheck, CodeQL, and g o vet, we discovered the best locations to dive
deeper into the code for manual analysis. Ultimately we focused on topics including (but
not limited to) potential cascading errors from rollbacks and user permissiveness.
Helm upgrade and Helm rollback. S ince we noticed a potential for cascading errors in a
rollback scenario, we attempted many manual upgrade and rollback processes that were
killed at various times during the process. We attempted to produce a situation in which a
Helm rollback would fail but remain completely hidden from the user. Helm history
successfully communicates the state of various upgrade and rollback scenarios even if the
exact error is not known. This gives the user enough information to remedy the situation
regardless of specifics (in the scenarios tested by Trail of Bits).
Decompression bombs. W e assessed this by manually analyzing any places where inputs
were unpacked to confirm that they could not cascade multiple levels deep. Helm could still
be susceptible to an o verlapping files compression bomb but the implementation of a
memory limit in places where Helm takes input (such as charts) is not valid due to the
variable nature of Helm releases and Kubernetes deployments.
YAML bombs. We tried different Y AML bomb denial-of-service payloads against y aml files
parsed by Helm. The g o-yaml library used seems to properly protect against this scenario,
but we sent a g o-yaml/yaml#637 pull request to improve this mitigation.
User permissions. W hen we analyzed permissions provided to users and processes to
assess if overly permissive states could cause potential harm, we discovered that
permissions are not checked for used configuration files (T OB-HELM-001) and the M kdirAll
operation (T OB-HELM-014) .
© 2020 Trail of Bits Helm Assessment | 4
Data validation. U sing various inputs, manual analysis, and debugging methods, we
assessed commands and components such as the plugin system, template-rendering code,
chart generation, parsing, and installation for insufficient validation that could lead to
injections, path traversals, denial-of-service scenarios, and other bugs.
© 2020 Trail of Bits Helm Assessment | 5
Recommendations Summary
This section aggregates all the recommendations made during the engagement. Short-term
recommendations address the immediate causes of issues. Long-term recommenda