[rabbitmq-discuss] Security/resource limit questions

Wed Jan 5 14:14:54 GMT 2011

Hi Christian

On 04/01/11 21:21, Christian Legnitto wrote:

> * What characters are allowed / expected in the routing key, binding
> topic, queue name, user name, and password? Is it just ASCII?

The AMQP 0.9.1 specification offers this:

"""
Short strings, used to hold short text properties. Short strings are 
limited to 255 octets and can be parsed with no risk of buffer overflows.

Short strings can carry up to 255 octets of UTF-8 data, but may not 
contain binary zero octets.

The routing key used for a topic exchange MUST consist of zero or more 
words delimited by dots. Each word may contain the letters A-Z and a-z 
and digits 0-9.

Standard message queues are prefixed by "amq."
"""

The routing key and queue name are short strings. I don't see any 
limitations on usernames and passwords, but SASL will complain if they 
contain null bytes.

RabbitMQ represents short strings as Erlang binaries internally without 
enforcing the alphabet from the specification.

> * What is the maximum length of the routing key, binding topic, queue
> name, user name, or password a client can specify?

Length of username and password appear unlimited. The rest are 255 bytes.

> * If a message is rejected due to hitting max length or an invalid
> character, what happens? How are the limits enforced? Rejection?
> Truncation? Conversion?

Clients should prevent this problem, e.g. 
com.rabbitmq.client.impl.ValueWriter in the Java client contains this:
"Short string too long [...] max = 255."

If a long shortstr reaches the broker it will produce a 
"method_field_shortstr_overflow" exception in the framing layer.

> * How many bindings are supported per queue? Is it possible to starve
> the broker of resources be specifying 100000s of bindings?

The number of bindings is limited by the amount of RAM you have. The 
broker has much more work to do in that case, so you can expect slower 
operation, depending on the exchange type.

> * Is it possible for malicious consumers to DOS the server by
> specifying 100000s of queues with 100000s of bindings listening to
> '#' on all exchanges?

Yes. Perhaps there should be some configurable limits...

> * Is it possible for a malicious producer to be able to affect the
> AMQP message / behavior by including control characters / AMQP escape
> sequences in the message payload?

No, as long as the framing is correct the broker does not care about the 
content.

> * Is it possible for malicious consumers to starve the broker of
> connections during protocol negotiation or consuming? What are the
> timeouts in place to prevent such an attack? Are they configurable?

The protocol negotiation phase has a 3 sec timeout to prevent that. The 
timeout is not configurable - you will need to modify the definitions in 
rabbit_reader.erl and recompile if you want a different value.

Regards

Emile