Florian Weimer of the Red Hat Product Security Team discovered that setting the federationtag attribute in an AMQP connection would turn the connection into a broker-to-broker connection, rather than a client-to-server connection. Because of this, incoming user IDs are not checked, so if a client were to set the federationtag attribute when establishing a regular AMQP connection, Qpid would no longer check the user ID on AMQP messages submitted by the client. The client can then supply any value and thus impersonate any user, since AMQP messages carry user information that identify the sender and message recipients, which use user names for authentication purposes. The client does have to authenticate, but any authentication method, including SASL ANONYMOUS would work.
A flaw was found in the way that qpidd handled incoming connections. If a client application were to send a large number of connections to qpidd, without terminating the connections with an incomplete handshake, qpidd would keep a file descriptor open for each connection. This could lead to excessive resource consumption by qpidd and could also block other legitimate connection requests.
This flaw has also been reported upstream:
https://issues.apache.org/jira/browse/QPID-2616 (RFE for disconnecting clients on incomplete handshakes)
https://issues.apache.org/jira/browse/QPID-4021 (the actual flaw)
Integer overflow in the qpid::framing::Buffer::checkAvailable function in Apache Qpid 0.20 and earlier allows remote attackers to cause a denial of service (crash) via a crafted message, which triggers an out-of-bounds read.
The low-level serializing/deserializing methods (putOctet, getOctet and so on) in the qpid::framing::Buffer class do not perform bounds checks before the operation. Instead, there is an assert after the operation which fails on out-of-bounds access.
If asserts are enabled, this results in a pre-authentication denial-of-service vulnerability. Red Hat builds disable asserts, so they are not affected by this vulnerability. Examining the protocol decoders showed that the read overrun is limited to very few bytes because all the large types perform proper length checking (so it seems impossible that an unmapped page can be reached and cause a crash). Regarding write overruns, there is a check of the buffer size against the encoded size (which is conceptually not possible for the read case), so there should not be any write buffer overrun, assuming that the encoded size account is completely correct.
The suggestion is to remove the asserts from putOctet/getOctet etc. and replace them with bounds checks which throw exceptions on failure.
Acknowledgements:
This issue was discovered by Florian Weimer of the Red Hat Product Security Team.
It was discovered that the AMQP type decoder was exposed pre-authentication because it was possible to send arbitrary types in the client-properties map in a connection.start-ok message. This is used to send an array with elements which are all of width zero and thus consume no space on the wire, but need storage after decoding by the server. On some systems, a suitably chosen SIZE value triggers the OOM killer and terminates the server process permanently.
Acknowledgements:
This issue was discovered by Florian Weimer of the Red Hat Product Security Team.