CVE-2024-56514

Karmada is a Kubernetes management system that allows users to run cloud-native applications across multiple Kubernetes clusters and clouds. Prior to version 1.12.0, both in karmadactl and karmada-operator, it is possible to supply a filesystem path, or an HTTP(s) URL to retrieve the custom resource definitions(CRDs) needed by Karmada. The CRDs are downloaded as a gzipped tarfile and are vulnerable to a TarSlip vulnerability. An attacker able to supply a malicious CRD file into a Karmada initialization could write arbitrary files in arbitrary paths of the filesystem. From Karmada version 1.12.0, when processing custom CRDs files, CRDs archive verification is utilized to enhance file system robustness. A workaround is available. Someone who needs to set flag --crd to customize the CRD files required for Karmada initialization when using karmadactl init to set up Karmada can manually inspect the CRD files to check whether they contain sequences such as ../ that would alter file paths, to determine if they potentially include malicious files. When using karmada-operator to set up Karmada, one must upgrade one's karmada-operator to one of the fixed versions.

Karmada is a Kubernetes management system that allows users to run cloud-native applications across multiple Kubernetes clusters and clouds. Prior to version 1.12.0, both in karmadactl and karmada-operator, it is possible to supply a filesystem path, or an HTTP(s) URL to retrieve the custom resource definitions(CRDs) needed by Karmada. The CRDs are downloaded as a gzipped tarfile and are vulnerable to a TarSlip vulnerability. An attacker able to supply a malicious CRD file into a Karmada initialization could write arbitrary files in arbitrary paths of the filesystem. From Karmada version 1.12.0, when processing custom CRDs files, CRDs archive verification is utilized to enhance file system robustness. A workaround is available. Someone who needs to set flag --crd to customize the CRD files required for Karmada initialization when using karmadactl init to set up Karmada can manually inspect the CRD files to check whether they contain sequences such as ../ that would alter file paths, to determine if they potentially include malicious files. When using karmada-operator to set up Karmada, one must upgrade one's karmada-operator to one of the fixed versions.

Impact

What kind of vulnerability is it? Who is impacted?

Both in karmadactl and karmada-operator, it is possible to supply a filesystem path, or an HTTP(s) URL to retrieve the custom resource definitions(CRDs) needed by karmada. The CRDs are downloaded as a gzipped tarfile and are vulnerable to a TarSlip vulnerability. An attacker able to supply a malicious CRD file into a karmada initialization could write arbitrary files in arbitrary paths of the filesystem.

Patches

Has the problem been patched? What versions should users upgrade to?

From karmada version v1.12.0, when processing custom CRDs files, CRDs archive verification is utilized to enhance file system robustness.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

When using karmadactl init to set up Karmada, if you need to set flag --crd to customize the CRD files required for karmada initialization, you can manually inspect the CRD files to check whether they contain sequences such as ../ that would alter file paths, to determine if they potentially include malicious files.

When using karmada-operator to set up Karmada, you must upgrade your karmada-operator to one of the fixed versions.

References

Are there any links users can visit to find out more?

1. Enhancements made from the Karmada community: https://github.com/karmada-io/karmada/pull/5713, https://github.com/karmada-io/karmada/pull/5703

Karmada is a Kubernetes management system that allows users to run cloud-native applications across multiple Kubernetes clusters and clouds. Prior to version 1.12.0, both in karmadactl and karmada-operator, it is possible to supply a filesystem path, or an HTTP(s) URL to retrieve the custom resource definitions(CRDs) needed by Karmada. The CRDs are downloaded as a gzipped tarfile and are vulnerable to a TarSlip vulnerability. An attacker able to supply a malicious CRD file into a Karmada initialization could write arbitrary files in arbitrary paths of the filesystem. From Karmada version 1.12.0, when processing custom CRDs files, CRDs archive verification is utilized to enhance file system robustness. A workaround is available. Someone who needs to set flag --crd to customize the CRD files required for Karmada initialization when using karmadactl init to set up Karmada can manually inspect the CRD files to check whether they contain sequences such as ../ that would alter file paths, to determine if they potentially include malicious files. When using karmada-operator to set up Karmada, one must upgrade one's karmada-operator to one of the fixed versions.

Karmada is a Kubernetes management system that allows users to run cloud-native applications across multiple Kubernetes clusters and clouds. Prior to version 1.12.0, both in karmadactl and karmada-operator, it is possible to supply a filesystem path, or an HTTP(s) URL to retrieve the custom resource definitions(CRDs) needed by Karmada. The CRDs are downloaded as a gzipped tarfile and are vulnerable to a TarSlip vulnerability. An attacker able to supply a malicious CRD file into a Karmada initialization could write arbitrary files in arbitrary paths of the filesystem. From Karmada version 1.12.0, when processing custom CRDs files, CRDs archive verification is utilized to enhance file system robustness. A workaround is available. Someone who needs to set flag --crd to customize the CRD files required for Karmada initialization when using karmadactl init to set up Karmada can manually inspect the CRD files to check whether they contain sequences such as ../ that would alter file paths, to determine if they potentially include malicious files. When using karmada-operator to set up Karmada, one must upgrade one's karmada-operator to one of the fixed versions.

Impact

What kind of vulnerability is it? Who is impacted?

Both in karmadactl and karmada-operator, it is possible to supply a filesystem path, or an HTTP(s) URL to retrieve the custom resource definitions(CRDs) needed by karmada. The CRDs are downloaded as a gzipped tarfile and are vulnerable to a TarSlip vulnerability. An attacker able to supply a malicious CRD file into a karmada initialization could write arbitrary files in arbitrary paths of the filesystem.

Patches

Has the problem been patched? What versions should users upgrade to?

From karmada version v1.12.0, when processing custom CRDs files, CRDs archive verification is utilized to enhance file system robustness.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

When using karmadactl init to set up Karmada, if you need to set flag --crd to customize the CRD files required for karmada initialization, you can manually inspect the CRD files to check whether they contain sequences such as ../ that would alter file paths, to determine if they potentially include malicious files.

When using karmada-operator to set up Karmada, you must upgrade your karmada-operator to one of the fixed versions.

References

Are there any links users can visit to find out more?

1. Enhancements made from the Karmada community: https://github.com/karmada-io/karmada/pull/5713, https://github.com/karmada-io/karmada/pull/5703

Karmada Tar Slips in CRDs archive extraction in github.com/karmada-io/karmada

These are all security issues fixed in the govulncheck-vulndb-0.0.20250108T191942-1.1 package on the GA media of openSUSE Tumbleweed.

This update for govulncheck-vulndb fixes the following issues:

• Update to version 0.0.20250108T191942 2025-01-08T19:19:42Z. Refs jsc#PED-11136 Go CVE Numbering Authority IDs added or updated with aliases:

  • GO-2025-3371 GHSA-2r2v-9pf8-6342
  • GO-2025-3374 CVE-2025-22130 GHSA-j4jw-m6xr-fv6c

• Update to version 0.0.20250107T160406 2025-01-07T16:04:06Z. Refs jsc#PED-11136 Go CVE Numbering Authority IDs added or updated with aliases:

  • GO-2025-3363 GO-2025-3364 GO-2025-3367 GO-2025-3368
  • GO-2024-3355 CVE-2024-54148 GHSA-r7j8-5h9c-f6fx
  • GO-2024-3356 CVE-2024-55947 GHSA-qf5v-rp47-55gg
  • GO-2024-3357 CVE-2024-56362 GHSA-xwx7-p63r-2rj8
  • GO-2024-3358 CVE-2024-45387 GHSA-vq94-9pfv-ccqr
  • GO-2024-3359 CVE-2024-28892 GHSA-5qww-56gc-f66c
  • GO-2024-3360 CVE-2024-25133 GHSA-wgqq-9qh8-wvqv
  • GO-2025-3361 CVE-2024-55196 GHSA-rv83-h68q-c4wq
  • GO-2025-3362 CVE-2025-21609 GHSA-8fx8-pffw-w498
  • GO-2025-3363 CVE-2024-56514 GHSA-cwrh-575j-8vr3
  • GO-2025-3364 CVE-2024-56513 GHSA-mg7w-c9x2-xh7r
  • GO-2025-3367 CVE-2025-21614 GHSA-r9px-m959-cxf4
  • GO-2025-3368 CVE-2025-21613 GHSA-v725-9546-7q7m

• Update to version 0.0.20241220T214820 2024-12-20T21:48:20Z. Refs jsc#PED-11136 Go CVE Numbering Authority IDs added or updated with aliases:

  • GO-2024-3101 GHSA-75qh-gg76-p2w4
  • GO-2024-3339 GHSA-8wcc-m6j2-qxvm

• Update to version 0.0.20241220T203729 2024-12-20T20:37:29Z. Refs jsc#PED-11136 Go CVE Numbering Authority IDs added or updated with aliases:

  • GO-2024-3101 GHSA-75qh-gg76-p2w4
  • GO-2024-3109 CVE-2024-43803 GHSA-pqfh-xh7w-7h3p
  • GO-2024-3333 CVE-2024-45338 GHSA-w32m-9786-jp63
  • GO-2024-3342 GHSA-hxr6-2p24-hf98
  • GO-2024-3343 CVE-2024-9779 GHSA-jhh6-6fhp-q2xp
  • GO-2024-3344 GHSA-32gq-x56h-299c
  • GO-2024-3349 CVE-2024-25131 GHSA-77c2-c35q-254w
  • GO-2024-3350 GHSA-5pf6-cq2v-23ww
  • GO-2024-3354 CVE-2024-12678 GHSA-hr68-hvgv-xxqf