June, 2024 saw the disclosure of a serious security issue in the popular RabbitMQ message broker system, tracked as CVE-2024-51988. This vulnerability enables users with basic API access and *insufficient* privileges to delete message queues–a function they should never be able to perform. Let’s break down what happened, how it works, and how you can safeguard your systems.

What is RabbitMQ?

RabbitMQ is an open source, widely used messaging broker. It lets different apps communicate by sending messages to queues, which then get processed by workers. It supports many protocols and is trusted by startups and huge enterprises alike.

The Bug: Missing configure Permission Check in RabbitMQ HTTP API

CVE-2024-51988 affects RabbitMQ installations using the HTTP management API. In versions prior to 3.12.11 (open source) and fixed Tanzu releases, it’s possible for a user to delete any queue on a vhost they have *some* permissions for, even if they’ve *not* been granted permissions to configure (or delete) that queue.

The problem?

When using the HTTP API, RabbitMQ did *not* check if the authenticated user had configure permission on the target queue before allowing a delete. All you needed was:

Let’s see this with a simplified example.

Scenario:
Suppose Alice is only supposed to *pull* (consume) messages from a queue named payments_queue on vhost /business, but NOT reconfigure or delete it.

Under normal circumstances, Alice’s permissions look like this

rabbitmqctl set_permissions -p /business alice "^$" "^payments_queue$" "^$"
# This means: configure: none, write: only payments_queue, read: none

But due to CVE-2024-51988, Alice *can still delete* payments_queue using the HTTP API!

With her basic credentials, Alice (or an attacker) could run a simple HTTP DELETE request

curl -i -u alice:supersecret \
  -X DELETE \
  http://rabbitmq-server:15672/api/queues/%2Fbusiness/payments_queue

Result:
HTTP/1.1 204 No Content
payments_queue is *gone*, even though Alice shouldn't have such powers.

References

- RabbitMQ Security Advisory CVE-2024-51988 *(Replace with actual link when published)*
- RabbitMQ Release Notes 3.12.11
- RabbitMQ Tanzu (VMware) Release Details

Tanzu RabbitMQ: 1.5.2, 3.13., 4.. and above

Upgrade instructions: Download Latest RabbitMQ

If you cannot upgrade immediately, disable the HTTP management plugin to close the attack vector

rabbitmq-plugins disable rabbitmq_management

Keep in mind, you will lose the web admin UI and HTTP API. For monitoring, consider using Prometheus and Grafana as alternatives.

Quick FAQ

Q: Is my RabbitMQ cluster affected?
If you use the HTTP API (via the management plugin) and have not upgraded to 3.12.11 or above, *yes*.

Q: Can someone exploit this over the Internet?
If your HTTP API is Internet-exposed, anyone with a valid login and *some* perms on a vhost can delete queues.

Q: Does this affect AMQP protocol?
No. The bug only affects queue deletes via the HTTP API.

Summary

CVE-2024-51988 made it too easy for users to delete queues they shouldn’t ever touch, all through the RabbitMQ management HTTP API. Fix your RabbitMQ deployment ASAP by upgrading or disabling the management plugin, and always review your user and API access policies.

Stay Safe

Message brokers are the backbone of modern infrastructures. A small permission slip like CVE-2024-51988 can have huge, immediate impact across your application stack. Please, upgrade now–and review your security controls regularly.


*Exclusive breakdown by [YourNameHere]*
*Follow @yourtwitter for more security news!*

Timeline

Published on: 11/06/2024 20:15:06 UTC
Last modified on: 11/08/2024 19:01:25 UTC