CVE-2024-43803 – The Bare Metal Operator (BMO) in Metal3 allows ... (How to Fix)

Q: What is the severity of CVE-2024-43803?

CVE-2024-43803 has a CVSS score of 4.9 (MEDIUM). The Bare Metal Operator (BMO) in Metal3 allows users with BareMetalHost creation/edit permissions to exfiltrate Kubernetes Secrets from any namespace by referencing them in BMH configuration. This affects multi-tenant clusters where non-admin users have BMH access but are supposed to be namespace-scoped.

📋 TL;DR

The Bare Metal Operator (BMO) in Metal3 allows users with BareMetalHost creation/edit permissions to exfiltrate Kubernetes Secrets from any namespace by referencing them in BMH configuration. This affects multi-tenant clusters where non-admin users have BMH access but are supposed to be namespace-scoped.

💻 Affected Systems

Products:

Metal3 Bare Metal Operator

Versions: Versions prior to 0.5.2, 0.6.2, and 0.7.0

Operating Systems: Any OS running Kubernetes with Metal3

Default Config Vulnerable: ⚠️ Yes

Notes: Only meaningful in clusters with non-admin users having BMH creation/edit permissions. Single-admin clusters or clusters where only admins have BMH access are less affected.

⚠️ Manual Verification Required

This CVE does not have specific version information in our database, so automatic vulnerability detection cannot determine if your system is affected.

Why? The CVE database entry doesn't specify which versions are vulnerable (no version ranges provided by the vendor/NVD).

🔒 Custom verification scripts are available for registered users. Sign up free to download automated test scripts.

Recommended Actions:

Review the CVE details at NVD
Check vendor security advisories for your specific version
Test if the vulnerability is exploitable in your environment
Consider updating to the latest version as a precaution

⚠️ Risk & Real-World Impact

🔴

Worst Case

Privileged users could exfiltrate sensitive secrets from any namespace, potentially compromising cluster credentials, API keys, or other confidential data stored in Kubernetes Secrets.

🟠

Likely Case

In multi-tenant environments, users could access secrets from other tenants' namespaces, violating namespace isolation and potentially accessing sensitive configuration data.

🟢

If Mitigated

With proper RBAC limiting BMH access to cluster admins only, the vulnerability has minimal impact as admins already have access to all secrets.

🌐 Internet-Facing: LOW - This is an internal Kubernetes API vulnerability requiring authenticated access to the cluster.

🏢 Internal Only: MEDIUM - Significant risk in multi-tenant clusters where users have BMH permissions but should be namespace-scoped.

🎯 Exploit Status

Public PoC: ✅ No

Weaponized: UNKNOWN

Unauthenticated Exploit: ✅ No

Complexity: LOW - Requires only BMH creation/edit permissions and knowledge of secret names/namespaces.

Exploitation requires authenticated Kubernetes API access with appropriate RBAC permissions for BareMetalHost resources.

🛠️ Fix & Mitigation

✅ Official Fix

Patch Version: v0.5.2, v0.6.2, v0.7.0 or later

Vendor Advisory: https://github.com/metal3-io/baremetal-operator/security/advisories

Restart Required: Yes

Instructions:

1. Upgrade BMO to v0.5.2, v0.6.2, or v0.7.0 depending on your current version. 2. Before upgrading, duplicate any BMC Secrets to the same namespace as their corresponding BMH. 3. After upgrade, remove old Secrets from other namespaces. 4. Restart BMO pods.

🔧 Temporary Workarounds

Namespace-scoped RBAC for Secrets

all

Configure BMO RBAC to be namespace-scoped for Secrets instead of cluster-scoped to prevent cross-namespace secret access.

kubectl edit clusterrole baremetal-operator
Modify Secret permissions to be namespace-scoped

🧯 If You Can't Patch

Restrict BareMetalHost creation/edit permissions to cluster administrators only
Implement network policies to limit BMO pod access to only necessary namespaces

🔍 How to Verify

Check if Vulnerable:

Check BMO version: kubectl get deployment -n metal3 baremetal-operator -o jsonpath='{.spec.template.spec.containers[0].image}'. If version is below 0.5.2, 0.6.2, or 0.7.0 (depending on your release track), you are vulnerable.

Check Version:

kubectl get deployment -n metal3 baremetal-operator -o jsonpath='{.spec.template.spec.containers[0].image}' | grep -o 'v[0-9]\+\.[0-9]\+\.[0-9]\+'

Verify Fix Applied:

After upgrade, attempt to create a BMH referencing a Secret from another namespace - this should fail with validation error.

📡 Detection & Monitoring

Log Indicators:

BMO logs showing attempts to read Secrets from different namespaces
Failed BMH validations due to cross-namespace secret references

Network Indicators:

Unusual API calls from BMO service account to Secrets API in different namespaces

SIEM Query:

kubernetes.pod_name:"baremetal-operator" AND (kubernetes.event.objectRef.resource:"secrets" AND kubernetes.event.objectRef.namespace != "metal3")

📊 Metadata

CVE ID: CVE-2024-43803

CVSS v3 Score: 4.9 (MEDIUM)

CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N

CWE: CWE-200

Published: September 3, 2024

Last Updated: September 3, 2024

🔗 References

📤 Share & Export

📄 Export Markdown 📋 Export JSON

🔗 Related Vulnerabilities

If you're affected by CVE-2024-43803, you might also want to check these: