CVE-2024-31463 in ironic-image
Summary
by MITRE • 04/17/2024
Ironic-image is an OpenStack Ironic deployment packaged and configured by Metal3. When the reverse proxy mode is enabled by the `IRONIC_REVERSE_PROXY_SETUP` variable set to `true`, 1) HTTP basic credentials are validated on the HTTPD side in a separate container, not in the Ironic service itself and 2) Ironic listens in host network on a private port 6388 on localhost by default. As a result, when the reverse proxy mode is used, any Pod or local Unix user on the control plane Node can access the Ironic API on the private port without authentication. A similar problem affects Ironic Inspector (`INSPECTOR_REVERSE_PROXY_SETUP` set to `true`), although the attack potential is smaller there. This issue affects operators deploying ironic-image in the reverse proxy mode, which is the recommended mode when TLS is used (also recommended), with the `IRONIC_PRIVATE_PORT` variable unset or set to a numeric value. In this case, an attacker with enough privileges to launch a pod on the control plane with host networking can access Ironic API and use it to modify bare-metal machine, e.g. provision them with a new image or change their BIOS settings. This vulnerability is fixed in 24.1.1.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 05/24/2024
The vulnerability described in CVE-2024-31463 affects the Ironic-image component within OpenStack Ironic deployments that are configured through Metal3 orchestration. This issue specifically manifests when reverse proxy mode is enabled through the IRONIC_REVERSE_PROXY_SETUP variable set to true. The fundamental flaw lies in the misconfiguration of authentication mechanisms where HTTP basic credentials are processed by the HTTPD side container rather than being validated within the Ironic service itself. This architectural gap creates a critical security weakness that undermines the intended authentication controls for the Ironic API.
The technical implementation of this vulnerability stems from the default configuration where Ironic listens on the host network interface on port 6388, bound to localhost by default. This configuration, combined with the reverse proxy setup, creates an attack vector where unauthorized access becomes possible through local system privileges. When IRONIC_PRIVATE_PORT is either unset or configured with a numeric value, the vulnerability becomes exploitable for attackers who possess sufficient privileges to launch pods on the control plane node with host networking capabilities. The flaw represents a classic case of insufficient access control where network-level protections fail to maintain proper authentication boundaries.
The operational impact of this vulnerability extends beyond simple unauthorized access to encompass significant system compromise capabilities. An attacker with the ability to execute pods on the control plane node can leverage this vulnerability to manipulate bare-metal machine configurations directly through the Ironic API. This includes provisioning new images onto servers, modifying BIOS settings, and potentially disrupting critical infrastructure operations. The attack surface is particularly concerning because it targets the core provisioning functionality of OpenStack Ironic, which governs physical machine management in cloud environments. The vulnerability affects not only Ironic itself but also Ironic Inspector when configured with INSPECTOR_REVERSE_PROXY_SETUP set to true, though the attack potential is reduced in the inspector component.
This vulnerability aligns with several cybersecurity frameworks and threat models, including CWE-284 which addresses improper access control, and ATT&CK techniques related to privilege escalation and lateral movement. The issue demonstrates how misconfigured reverse proxy setups can create authentication bypass scenarios that undermine the security posture of cloud infrastructure components. Organizations deploying ironic-image in reverse proxy mode should consider this vulnerability as a critical risk requiring immediate remediation. The fix implemented in version 24.1.1 addresses the core authentication flow by ensuring proper credential validation within the Ironic service itself rather than delegating to separate containers, thereby restoring the intended security boundaries and access controls for bare-metal provisioning operations.