CVE-2024-43803

The Bare Metal Operator (BMO) implements a Kubernetes API for managing bare metal hosts in Metal3. The BareMetalHost (BMH) CRD allows the userData, metaData, and networkData for the provisioned host to be specified as links to Kubernetes Secrets. There are fields for both the Name and Namespace of the Secret, meaning that versions of the baremetal-operator prior to 0.8.0, 0.6.2, and 0.5.2 will read a Secret from any namespace. A user with access to create or edit a BareMetalHost can thus exfiltrate a Secret from another namespace by using it as e.g. the userData for provisioning some host (note that this need not be a real host, it could be a VM somewhere).

BMO will only read a key with the name value (or userData, metaData, or networkData), so that limits the exposure somewhat. value is probably a pretty common key though. Secrets used by other BareMetalHosts in different namespaces are always vulnerable. It is probably relatively unusual for anyone other than cluster administrators to have RBAC access to create/edit a BareMetalHost. This vulnerability is only meaningful, if the cluster has users other than administrators and users' privileges are limited to their respective namespaces.

The patch prevents BMO from accepting links to Secrets from other namespaces as BMH input. Any BMH configuration is only read from the same namespace only. The problem is patched in BMO releases v0.7.0, v0.6.2 and v0.5.2 and users should upgrade to those versions. Prior upgrading, duplicate the BMC Secrets to the namespace where the corresponding BMH is. After upgrade, remove the old Secrets. As a workaround, an operator can configure BMO RBAC to be namespace scoped for Secrets, instead of cluster scoped, to prevent BMO from accessing Secrets from other namespaces.

The Bare Metal Operator (BMO) implements a Kubernetes API for managing bare metal hosts in Metal3. The BareMetalHost (BMH) CRD allows the userData, metaData, and networkData for the provisioned host to be specified as links to Kubernetes Secrets. There are fields for both the Name and Namespace of the Secret, meaning that versions of the baremetal-operator prior to 0.8.0, 0.6.2, and 0.5.2 will read a Secret from any namespace. A user with access to create or edit a BareMetalHost can thus exfiltrate a Secret from another namespace by using it as e.g. the userData for provisioning some host (note that this need not be a real host, it could be a VM somewhere).

BMO will only read a key with the name value (or userData, metaData, or networkData), so that limits the exposure somewhat. value is probably a pretty common key though. Secrets used by other BareMetalHosts in different namespaces are always vulnerable. It is probably relatively unusual for anyone other than cluster administrators to have RBAC access to create/edit a BareMetalHost. This vulnerability is only meaningful, if the cluster has users other than administrators and users' privileges are limited to their respective namespaces.

The patch prevents BMO from accepting links to Secrets from other namespaces as BMH input. Any BMH configuration is only read from the same namespace only. The problem is patched in BMO releases v0.7.0, v0.6.2 and v0.5.2 and users should upgrade to those versions. Prior upgrading, duplicate the BMC Secrets to the namespace where the corresponding BMH is. After upgrade, remove the old Secrets. As a workaround, an operator can configure BMO RBAC to be namespace scoped for Secrets, instead of cluster scoped, to prevent BMO from accessing Secrets from other namespaces.

Impact

The Bare Metal Operator (BMO) implements a Kubernetes API for managing bare metal hosts in Metal3. The BareMetalHost (BMH) CRD allows the userData, metaData, and networkData for the provisioned host to be specified as links to Kubernetes Secrets. There are fields for both the Name and Namespace of the Secret, meaning that the baremetal-operator will read a Secret from any namespace. A user with access to create or edit a BareMetalHost can thus exfiltrate a Secret from another namespace by using it as e.g. the userData for provisioning some host (note that this need not be a real host, it could be a VM somewhere).

Limiting factors

BMO will only read a key with the name value (or userData, metaData, or networkData), so that limits the exposure somewhat. value is probably a pretty common key though. Secrets used by other BareMetalHosts in different namespaces are always vulnerable.

It is probably relatively unusual for anyone other than cluster administrators to have RBAC access to create/edit a BareMetalHost. This vulnerability is only meaningful, if the cluster has users other than administrators and users' privileges are limited to their respective namespaces.

Patches

The patch prevents BMO from accepting links to Secrets from other namespaces as BMH input. Any BMH configuration is only read from the same namespace only.

The problem is patched in BMO releases v0.8.0, v0.6.2 and v0.5.2 and users should upgrade to those versions. Prior upgrading and if needed, duplicate the BMC Secrets to the namespace where the corresponding BMH is. After upgrade, remove the old Secrets.

Workarounds

Operator can configure BMO RBAC to be namespace scoped for Secrets, instead of cluster scoped, to prevent BMO from accessing Secrets from other namespaces.

References

• https://nvd.nist.gov/vuln/detail/CVE-2024-43803
• https://github.com/metal3-io/baremetal-operator/pull/1929
• https://github.com/metal3-io/baremetal-operator/pull/1930
• https://github.com/metal3-io/baremetal-operator/pull/1931

The Bare Metal Operator (BMO) implements a Kubernetes API for managing bare metal hosts in Metal3. The BareMetalHost (BMH) CRD allows the userData, metaData, and networkData for the provisioned host to be specified as links to Kubernetes Secrets. There are fields for both the Name and Namespace of the Secret, meaning that versions of the baremetal-operator prior to 0.8.0, 0.6.2, and 0.5.2 will read a Secret from any namespace. A user with access to create or edit a BareMetalHost can thus exfiltrate a Secret from another namespace by using it as e.g. the userData for provisioning some host (note that this need not be a real host, it could be a VM somewhere).

BMO will only read a key with the name value (or userData, metaData, or networkData), so that limits the exposure somewhat. value is probably a pretty common key though. Secrets used by other BareMetalHosts in different namespaces are always vulnerable. It is probably relatively unusual for anyone other than cluster administrators to have RBAC access to create/edit a BareMetalHost. This vulnerability is only meaningful, if the cluster has users other than administrators and users' privileges are limited to their respective namespaces.

The patch prevents BMO from accepting links to Secrets from other namespaces as BMH input. Any BMH configuration is only read from the same namespace only. The problem is patched in BMO releases v0.7.0, v0.6.2 and v0.5.2 and users should upgrade to those versions. Prior upgrading, duplicate the BMC Secrets to the namespace where the corresponding BMH is. After upgrade, remove the old Secrets. As a workaround, an operator can configure BMO RBAC to be namespace scoped for Secrets, instead of cluster scoped, to prevent BMO from accessing Secrets from other namespaces.

The Bare Metal Operator (BMO) implements a Kubernetes API for managing bare metal hosts in Metal3. The BareMetalHost (BMH) CRD allows the userData, metaData, and networkData for the provisioned host to be specified as links to Kubernetes Secrets. There are fields for both the Name and Namespace of the Secret, meaning that versions of the baremetal-operator prior to 0.8.0, 0.6.2, and 0.5.2 will read a Secret from any namespace. A user with access to create or edit a BareMetalHost can thus exfiltrate a Secret from another namespace by using it as e.g. the userData for provisioning some host (note that this need not be a real host, it could be a VM somewhere).

BMO will only read a key with the name value (or userData, metaData, or networkData), so that limits the exposure somewhat. value is probably a pretty common key though. Secrets used by other BareMetalHosts in different namespaces are always vulnerable. It is probably relatively unusual for anyone other than cluster administrators to have RBAC access to create/edit a BareMetalHost. This vulnerability is only meaningful, if the cluster has users other than administrators and users' privileges are limited to their respective namespaces.

The patch prevents BMO from accepting links to Secrets from other namespaces as BMH input. Any BMH configuration is only read from the same namespace only. The problem is patched in BMO releases v0.7.0, v0.6.2 and v0.5.2 and users should upgrade to those versions. Prior upgrading, duplicate the BMC Secrets to the namespace where the corresponding BMH is. After upgrade, remove the old Secrets. As a workaround, an operator can configure BMO RBAC to be namespace scoped for Secrets, instead of cluster scoped, to prevent BMO from accessing Secrets from other namespaces.

Impact

The Bare Metal Operator (BMO) implements a Kubernetes API for managing bare metal hosts in Metal3. The BareMetalHost (BMH) CRD allows the userData, metaData, and networkData for the provisioned host to be specified as links to Kubernetes Secrets. There are fields for both the Name and Namespace of the Secret, meaning that the baremetal-operator will read a Secret from any namespace. A user with access to create or edit a BareMetalHost can thus exfiltrate a Secret from another namespace by using it as e.g. the userData for provisioning some host (note that this need not be a real host, it could be a VM somewhere).

Limiting factors

BMO will only read a key with the name value (or userData, metaData, or networkData), so that limits the exposure somewhat. value is probably a pretty common key though. Secrets used by other BareMetalHosts in different namespaces are always vulnerable.

It is probably relatively unusual for anyone other than cluster administrators to have RBAC access to create/edit a BareMetalHost. This vulnerability is only meaningful, if the cluster has users other than administrators and users' privileges are limited to their respective namespaces.

Patches

The patch prevents BMO from accepting links to Secrets from other namespaces as BMH input. Any BMH configuration is only read from the same namespace only.

The problem is patched in BMO releases v0.8.0, v0.6.2 and v0.5.2 and users should upgrade to those versions. Prior upgrading and if needed, duplicate the BMC Secrets to the namespace where the corresponding BMH is. After upgrade, remove the old Secrets.

Workarounds

Operator can configure BMO RBAC to be namespace scoped for Secrets, instead of cluster scoped, to prevent BMO from accessing Secrets from other namespaces.

References

• https://nvd.nist.gov/vuln/detail/CVE-2024-43803
• https://github.com/metal3-io/baremetal-operator/pull/1929
• https://github.com/metal3-io/baremetal-operator/pull/1930
• https://github.com/metal3-io/baremetal-operator/pull/1931

The Bare Metal Operator (BMO) can expose particularly named secrets from other namespaces via BMH CRD in github.com/metal3-io/baremetal-operator

These are all security issues fixed in the govulncheck-vulndb-0.0.20241220T214820-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