1. Cncf-Helm
  2. Topics

Security release of ChartMuseum v0.8.1

Matt Farina
 

A security vulnerability was discovered in ChartMuseum. The following details can be found on the Helm blog  the root source for this disclosure, but are reproduced here as well.

Security researcher Bernard Wagner of Entersekt discovered a vulnerability in ChartMuseum, impacting all versions of ChartMuseum between ChartMuseum >=0.1.0 and < 0.8.1. A specially crafted chart could be uploaded that caused the uploaded archive to be saved outside of the intended location.

When ChartMuseum is configured for multitenancy the specially crafted chart could be uploaded to one tenant but saved in the location of another tenant. This includes overwriting a chart at a version in the other tenant.

Additionally, if ChartMusem is configured to use a file system the uploaded Chart archive may be uploaded to locations outside of the storage directory. It could be uploaded to any place the ChartMuseum application binary has write permission to.

We are unaware of any public exploits caused by this issue.

Details

When a chart archive is uploaded the name of the chart, as listed in the `Chart.yaml` file, is used when creating the path location to save the file. The name is joined with the directory or object storage prefix path. The chart name was not sanitized or validated. This allowed directory traversal characters, such as `../..`, to be used in the name and affect the directory the archive file is saved within.

When the Helm client creates a chart archive, via the `helm package` command, it validates that the chart name and encapsulating directory match. It will not generate a chart archive with directory traversal characters.

Fix

Update to ChartMuseum >= 0.8.1

To prevent this from happening, ChartMuseum now checks the name of the chart to make sure there are no directory traversal characters in the name before using it to save the archive. If the name contains directory traversal characters the API will return a 400 Bad Request response and message to signify the name issue.

-- 
Matt Farina
mattfarina.com
Josh Dolitsky
 

In a typical ChartMuseum installation, uploads are protected by a single basic auth username/password combo. In this scenario, anyone with this credential pair can upload chart packages to the wrong tenant, without using this vulnerability.

When using bearer/token auth, or when using ChartMuseum as a backend service, this issue may be more cause for concern.

Keep in mind, however, that this vulnerability also allows file uploads outside the storage root (depending on permissions and configuration).

If you have deployed ChartMuseum using the chartmuseum/chartmuseum Docker image, please upgrade to the following tag which contains the fix: v0.8.1

I've also put together a simple tool which can be used to verify that your systems have not been affected by this:

Apologies for any inconvenience this may cause. If you have any questions, please feel free to reach out to me directly on Slack/Twitter (@jdolitsky).

Thanks,
Josh Dolitsky

On Mon, Jan 14, 2019 at 2:04 PM Matt Farina <matt@...> wrote:
A security vulnerability was discovered in ChartMuseum. The following details can be found on the Helm blog  the root source for this disclosure, but are reproduced here as well.

Security researcher Bernard Wagner of Entersekt discovered a vulnerability in ChartMuseum, impacting all versions of ChartMuseum between ChartMuseum >=0.1.0 and < 0.8.1. A specially crafted chart could be uploaded that caused the uploaded archive to be saved outside of the intended location.

When ChartMuseum is configured for multitenancy the specially crafted chart could be uploaded to one tenant but saved in the location of another tenant. This includes overwriting a chart at a version in the other tenant.

Additionally, if ChartMusem is configured to use a file system the uploaded Chart archive may be uploaded to locations outside of the storage directory. It could be uploaded to any place the ChartMuseum application binary has write permission to.

We are unaware of any public exploits caused by this issue.

Details

When a chart archive is uploaded the name of the chart, as listed in the `Chart.yaml` file, is used when creating the path location to save the file. The name is joined with the directory or object storage prefix path. The chart name was not sanitized or validated. This allowed directory traversal characters, such as `../..`, to be used in the name and affect the directory the archive file is saved within.

When the Helm client creates a chart archive, via the `helm package` command, it validates that the chart name and encapsulating directory match. It will not generate a chart archive with directory traversal characters.

Fix

Update to ChartMuseum >= 0.8.1

To prevent this from happening, ChartMuseum now checks the name of the chart to make sure there are no directory traversal characters in the name before using it to save the archive. If the name contains directory traversal characters the API will return a 400 Bad Request response and message to signify the name issue.

-- 
Matt Farina
mattfarina.com
Matt Farina
 

A CVE id has been assigned for this vulnerability as CVE-2019-1000009.

-- 
Matt Farina
mattfarina.com



On Jan 14, 2019, at 3:04 PM, Matthew Farina <matt@...> wrote:

A security vulnerability was discovered in ChartMuseum. The following details can be found on the Helm blog  the root source for this disclosure, but are reproduced here as well.

Security researcher Bernard Wagner of Entersekt discovered a vulnerability in ChartMuseum, impacting all versions of ChartMuseum between ChartMuseum >=0.1.0 and < 0.8.1. A specially crafted chart could be uploaded that caused the uploaded archive to be saved outside of the intended location.

When ChartMuseum is configured for multitenancy the specially crafted chart could be uploaded to one tenant but saved in the location of another tenant. This includes overwriting a chart at a version in the other tenant.

Additionally, if ChartMusem is configured to use a file system the uploaded Chart archive may be uploaded to locations outside of the storage directory. It could be uploaded to any place the ChartMuseum application binary has write permission to.

We are unaware of any public exploits caused by this issue.

Details

When a chart archive is uploaded the name of the chart, as listed in the `Chart.yaml` file, is used when creating the path location to save the file. The name is joined with the directory or object storage prefix path. The chart name was not sanitized or validated. This allowed directory traversal characters, such as `../..`, to be used in the name and affect the directory the archive file is saved within.

When the Helm client creates a chart archive, via the `helm package` command, it validates that the chart name and encapsulating directory match. It will not generate a chart archive with directory traversal characters.

Fix

Update to ChartMuseum >= 0.8.1

To prevent this from happening, ChartMuseum now checks the name of the chart to make sure there are no directory traversal characters in the name before using it to save the archive. If the name contains directory traversal characters the API will return a 400 Bad Request response and message to signify the name issue.

-- 
Matt Farina
mattfarina.com

1 - 3 of 3