[rabbitmq-discuss] Forcing headers on incoming commands

[Rob Harrop]

Hi Mike,

On Mon, 27 Dec 2010 21:26:04 -0500, Mike Keen <mkeen.atl at gmail.com> wrote:
> Hello,
> 
> I'm part of a small group working on a realtime social game powered by
> RabbitMQ/STOMP and run on Flash clients in the browser.
> 
> We've run into some security concerns related to exposing our STOMP port
to
> the public. Specifically, we've noticed that without the "exclusive:
true"
> header in an initial subscription (even to an anonymous queue), and the
> socket is dropped before the client sends a clean disconnect, the queues
> remain open for a pretty long time (at least a few minutes). This has
lead
> to the concern that an attacker might be able to create any number of
> queues
> that could hang around and waste memory, or even lead to memory being
> exhausted.

A few things have changed in the STOMP adapter that make this a bit
different now. 

Most importantly, custom headers such as 'exclusive' are no longer
supported. Instead, we now support destination types with set semantics.
The support destinations are /queue/<name>, /topic/<name> and
/exchange/<name>/<routing_key>. The /queue and /topic types are designed to
work as closely to the corresponding types in ActiveMQ as possible.

For /queue, created queues are now durable and are not exclusive. This
means that it is a separate administration task to clean up queues. This is
designed to match ActiveMQ.

For /topic, a queue is created per SUBSCRIPTION, but only lasts for the
duration of that subscription. That means that after all subscribers to a
topic destination disconnect, no queues exist for that topic.

I recently updated the README for this. The changes are still going
through QA, but the relevant revision can be found here:
http://hg.rabbitmq.com/rabbitmq-stomp/file/6cfb4d0f9cd9/README.md.

> 
> Two questions considering the above:
> 
> 1) Is it possible to set, through the config file, to force
queue.exclusive
> = true on every new queue creation on the server?

This isn't possible at the moment. I don't think we have any plans to
introduce such a feature.

> 
> 2) Is this a legitimate security concern? Or would a massive number of
> queues (all bound to a topic exchange) not be enough to cause
performance
> issues?

Well, importantly, you can only create queues if you are an authenticated
user, so the attacker would need to get past that hurdle first. I have a
task to add SSL support for STOMP which will make sending credentials in
the CONNECT header a lot safer :)

Also, if you're using  /topic destinations (probably the easiest way in
the new adapter to access topic semantics), then you would have to have a
large number of active subscriptions in order to have a large number of
queues. RabbitMQ handles large numbers of queues nicely, so for this to be
a major problem, you'd need to a large number of subscriptions created on a
topic that has a large publish volume. The subscriptions would have to be
in ack:client mode and would need to *not* ack the messsages. Even then,
new support in RabbitMQ 2.2.0 for handling large ack volumes means that you
a really only limited by disk space when it comes to the ack backlog. 

One possible issue is that storing transaction state for STOMP transaction
takes up a non-trivial amount of RAM, so creating massive transactions and
not committing them could lead to out of memory. For this reason, I can
imagine a configuration option that allows for transaction support to be
disabled.

I hope this helps.

> 
> Thanks in advance for your help.
> 
> Mike