Penetration Test Report (Cure53): HLM 01 report

Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Security-Review Report Helm 10.-11.2019
Cure53, Dr.-Ing. M. Heiderich, M. Wege, MSc. D. Weißer, B. Walny, J. Larsson, BSc. J. Hector
Index
Introduction
Scope
Test Methodology
Phase 1: General Security Posture Checks
Phase 2: Manual Code Auditing
Phase 1: General Security Posture Checks
Application/Service/Project Specifics
Language Specifics
External Libraries & Frameworks
Access Control
Logging/Monitoring
Unit/Regression Testing
Documentation
Organization/Team/Infrastructure Specifics
Security Contact
Security Fix Handling
Bug Bounty
Bug Tracking & Review Process
Evaluating the Overall Posture
Phase 2: Manual Code Auditing
Signing and Verification Code
Chart Files Manipulation
TLS Certificates/Handling
Miscellaneous Issues
HLM-01-001 Packaging: Denial-of-Service via Symbolic Links (Low)
Conclusions & Verdict
Cure53, Berlin · 11/04/19 1/14
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Introduction
“Helm helps you manage Kubernetes applications - Helm Charts help you define, install,
and upgrade even the most complex Kubernetes application. Charts are easy to create,
version, share, and publish - so start using Helm and stop the copy-and-paste. The
latest version of Helm is maintained by the CNCF - in collaboration with Microsoft,
Google, Bitnami and the Helm contributor community.”
From https://helm.sh/
This report documents a security assessment carried out by Cure53 and targeting the
Helm complex. Specifically, this October 2019 project featured a security posture review
and an evaluation of maturity levels observed as regards the Helm software, as well as
its surrounding infrastructure and process implementations. It is important to note that
the review was commissioned to Cure53 by CNCF, which also sponsored the
assessment.
The project was executed in close collaboration of the Cure53, Helm and CNCF teams.
The project took on a broad view of the Helm complex as a whole, Cure53 not only
examined the code qualities but also looked at various aspects like the in-house test
coverage, security-related processes and responses, as well as incident handling and
similar matters at a meta-level. The Cure53 team spent the allocated project budget on
inspecting the code and implementation, yet the majority of work has been invested into
assessing various high-level, advanced and meta-properties and processes of the Helm
project.
To correspond with the objectives, the project has been split into two stages, which also
mark two chapters of this report. While Phase 1 pertains to general security posture
checks, Phase 2 reflects the findings stemming from the manual code auditing stage of
the project. The outcomes from each phase are discussed in more detail later on in this
document. Nevertheless, it should be clarified that the security posture was evaluated by
Cure53 on the basis of several approaches and criteria, including source code
inspection and analysis of the maturity levels found on the Helm items in scope.
The project progressed in a timely and efficient fashion. Six senior testers from the
Cure53 team spent a total of eighteen person-days on the Helm scope, ultimately
reaching good coverage. Communication with the Helm team was done in a dedicated
Slack channel residing on the CNCF workspace. All involved Cure53 testers and
relevant Helm personnel could join in the discussions on Slack, making the exchanges
productive and effective.
Cure53, Berlin · 11/04/19 2/14
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
In the following sections, the report first sheds light on the scope of the audit, while also
furnishing more details on the deployed methodology, so as to foster understanding of
what Cure53 took into consideration, why and with what results. Subsequently, the
report moves on the code review stage, pointing out to a single finding spotted in the
given timeframe of the project. Finally, the report will close with a conclusion in which the
Cure53 team summarizes the results of this October 2019 security review of the Helm
complex. Elaborating on the review, audits and inspections, this section ends with a final
verdict about the maturity of Helm from a security standpoint, as well as incorporates
some recommendations on the next steps that Cure53 envisions and advises to the
Helm team.
Scope
• Helm 3.0.0 (dev-v3 branch)
◦ Helm codebase
▪ https://github.com/helm/helm/tree/master
▪ Commit: 34b930cb9db8dba90aaba6299200c34664219a57
◦ Helm project’s security posture and maturity levels
Cure53, Berlin · 11/04/19 3/14
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Test Methodology
The following paragraphs describe the metrics and methodologies used to evaluate the
security posture of the Helm project and codebase. In addition, they include the results
for individual areas of the project’s security properties that were either selected by
Cure53 or requested by other involved parties for closer inspection.
As noted in the Introduction, the test was divided into two phases, each fulfilling different
goals. In the first phase, the focus was on the general security posture of the code and
the project. Further, Cure53 examined the processes that the Helm team has made
available for security reports, also as relates disclosure and general hardening
approaches. In the second phase, the work has shifted to the manual source code
review of specific code areas.
Phase 1: General Security Posture Checks
In this part, Cure53 looked at the General security posture of the Helm project and
inspected the overall code quality from a high-level perspective. Some of the indicators
entailed test coverage, security vulnerability disclosure process, threat modeling
approaches and general code hardening measures. The sum of observations from
across these arenas have been used to describe the maturity levels of this project at a
meta-level, independently of the security qualities of the provided code and compiled
binaries.
Later chapters in this report will dive into the details of the inspected items, justifying
these choices and presenting the results in the specific case of the Helm software
project.
Phase 2: Manual Code Auditing
In this part, Cure53 performed a Small-scale classic code review and attempted to
identify security-relevant areas of the project’s codebase and inspect them for common
flaws.
Unlike standard processes in a usual penetration test and code audit, this phase only
took a few days. As such, it was a brief rather than in-depth inspection and should be
seen as an initial probing aimed at evaluating whether more thorough code audits should
be recommended. The goal was not to reach an extensive coverage but to gain an
impression about the quality. The performed tasks assist Cure53 in making a judgement
call as to whether Helm needs additional tests and - if so - what kinds of tests those
should be.
Cure53, Berlin · 11/04/19 4/14
Dr.-Ing. Mario Heiderich, Cure53
Bielefelder Str. 14
D 10709 Berlin
cure53.de · mario@cure53.de
Later chapters in this report will give more details on what was being inspected, why and
with what implications for the Helm software complex.
Phase 1: General Security Posture Checks
This phase is meant to provide a more detailed overview of the Helm project’s security
properties that are independent of both its code and the software itself. To facilitate clear
flow and understanding, this section is divided into two subsections, where the first part
consists of elements specific to the application and the project. The second part looks at
the element linked more strongly to the organizational/team aspect. Lastly, each aspect
below is taken into account and an evaluation of the overall security posture is based on
cross-comparative analysis of all observations and findings.
• A general high-lev