Executive Summary

This vulnerability exists in OpenStack's oslo.messaging library, specifically in its RabbitMQ driver versions 1.0.0 through 17.3.0. The issue is that the driver does not verify the RabbitMQ broker's hostname during TLS handshakes, even though it validates the certificate chain when ssl_ca_file is configured.

Because the expected broker hostname is not passed to the TLS stack, any certificate signed by the deployment's trusted CA is accepted regardless of hostname. This allows an attacker who can intercept control-plane traffic to impersonate the RabbitMQ broker and perform man-in-the-middle (MITM) attacks on RPC and notification traffic between OpenStack services.

All OpenStack services using oslo.messaging with RabbitMQ over TLS are affected by this vulnerability.

Useful 0 Not Useful 0

Compliance Impact

This vulnerability allows an attacker who can intercept control-plane traffic to impersonate the RabbitMQ broker and perform man-in-the-middle attacks on RPC and notification traffic between OpenStack services.

Such man-in-the-middle attacks can lead to unauthorized access, interception, or manipulation of sensitive data transmitted between services, potentially violating data protection requirements mandated by standards like GDPR and HIPAA.

Because the vulnerability undermines the integrity and confidentiality of communication channels, affected deployments may fail to meet compliance obligations related to secure data transmission and protection against unauthorized access.

Mitigations include enabling hostname verification by default in oslo.messaging 18.0.0 and ensuring proper certificate configurations, which are necessary steps to restore compliance with security best practices required by these regulations.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability arises because the oslo.messaging RabbitMQ driver does not perform TLS hostname verification when connecting to the message broker, even if certificate chain validation is enabled.

To detect if your system is vulnerable, you should check the oslo.messaging version and configuration settings related to TLS hostname verification.

• Verify the oslo.messaging version installed: it is vulnerable if the version is >=1.0.0 and <16.2.0, >=17.0.0 and <17.1.1, or >=17.2.0 and <17.3.1.
• Check the configuration file (usually under /etc/oslo/messaging.conf or similar) for the [oslo_messaging_rabbit] section and see if ssl_enforce_hostname_verification is set to True.
• If ssl_enforce_hostname_verification is not set or set to False, the system is likely vulnerable.

For network detection, you can monitor TLS handshakes between OpenStack services and RabbitMQ brokers to see if hostname verification is performed. However, no specific commands are provided in the resources.

Suggested commands to check versions and configurations include:

• Check oslo.messaging version: `pip show oslo.messaging` or `rpm -qa | grep oslo.messaging`
• Check configuration for hostname verification: `grep ssl_enforce_hostname_verification /etc/oslo/messaging.conf`
• Inspect RabbitMQ broker certificates to ensure they include SAN entries matching hostnames used in transport_url.

Useful 0 Not Useful 0

Impact Analysis

The vulnerability allows an attacker with access to the control plane network and a certificate from the trusted deployment CA to impersonate the RabbitMQ broker.

This impersonation enables man-in-the-middle attacks on RPC and notification traffic, which are critical communication channels between OpenStack services such as Nova, Neutron, Cinder, Heat, Ironic, and Glance.

Such attacks can lead to interception, modification, or disruption of sensitive control-plane messages, potentially compromising the integrity and confidentiality of the cloud infrastructure's operations.

Useful 0 Not Useful 0

Mitigation Strategies

To mitigate this vulnerability, operators should ensure that RabbitMQ broker certificates include Subject Alternative Name (SAN) entries that match the hostnames used in the transport_url.

Set the configuration option ssl_enforce_hostname_verification=True in the [oslo_messaging_rabbit] section to enable hostname verification.

Verify that Kombu is version 5.2.0 or higher if using multi-host setups before enabling hostname verification.

Upgrading oslo.messaging to version 18.0.0 or later is recommended, as it enables hostname verification by default and provides a secure-by-default behavior.

Be aware that enabling hostname verification may cause disruptions in deployments where broker certificates lack correct SAN entries, so testing and validation are advised.

Useful 0 Not Useful 0