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.
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.
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.
It was reported [1] that Apache QPID would crash when receiving data from a client that is not valid AMQP data, resulting in a shut down of the cluster rather than the client being disconnected. This was corrected upstream by r785788 [2].
[1] https://bugzilla.redhat.com/showbug.cgi?id=506580 [2] http://svn.apache.org/viewvc?revision=785788&view=revision
It was reported [1], [2] that Apache QPID would crash due to a NULL pointer dereference when a remote, authenticated user attempted to redeclare an existing exchange and add a new alternate exchange. This would result in a denial of service condition of the server. This was corrected upstream by r811188 [3].
[1] https://issues.apache.org/jira/browse/QPID-2080 [2] https://bugzilla.redhat.com/showbug.cgi?id=517751 [3] http://svn.apache.org/viewvc?revision=811188&view=revision
It was discovered that SSL connections to the MRG broker could easily be blocked. If a client or application initiated a connection to the MRG broker's listening SSL port, the client connection would block access to the port until the SSL handshake completes (or fails). If a client failed to proceed with it, then the thread was never freed to process other connections, denying service to other clients. Only SSL connections were affected by this issue, and SSL support is not enabled by default.
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.
Apache QPID 0.14, 0.16, and earlier uses a NullAuthenticator mechanism to authenticate catch-up shadow connections to AMQP brokers, which allows remote attackers to bypass authentication.
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)
XML external entity (XXE) vulnerability in the XML Exchange module in Apache Qpid 0.30 allows remote attackers to cause outgoing HTTP connections via a crafted message.
It was reported [1] that an attacker can gain access to qpidd as an anonymous user, even if the ANONYMOUS mechanism is disallowed.
A patch is available (https://issues.apache.org/jira/browse/QPID-6325) that addresses this vulnerability. The fix will be included in subsequent releases, but can be applied to 0.30 if desired.
[1]: http://seclists.org/bugtraq/2015/Jan/122
It was reported [1] that certain unexpected protocol sequences cause the broker process to crash due to insufficient checking. Three distinct cases were identified as follows:
The AMQP 0-10 protocol defines a sequence set containing id ranges. The qpidd broker can be crashed by sending it a sequence-set containing an invalid range, where the start of the range is after the end. This condition causes an assertion, which causes the broker process to exit.
The AMQP 0-10 protocol defines header- and body- segments that may follow certain commands. The only command for which such segments are expected by qpidd is the message-transfer command. If another command is sent that includes header and/or body segments, this will cause a segmentation fault in the broker process, causing it then to exit.
The AMQP 0-10 protocol defines a session-gap control that can be sent on any established session. The qpidd broker does not support this control and responds with an appropriate error if requested on an established session. However, if the control is sent before the session is opened, the brokers handling causes an assertion which results in the broker process exiting.
A patch is available (https://issues.apache.org/jira/browse/QPID-6310) that handles all these errors by sending an exception control to the remote peer and leave the broker available to all other users.
[1]: http://mail-archives.apache.org/modmbox/qpid-users/201501.mbox/%3c54B4F4AC.8030109@apache.org%3e
Acknowledgements:
Red Hat would like to thank the Apache Software Foundation for reporting this issue. Upstream acknowledges G. Geshev from MWR Labs as the original reporter.
A flaw was found in qpid where it would accept any password or SASL mechanism, provided the remote user knew a valid cluster username. This would give a malicious remote attacker unauthorized access to the cluster where they would be able to receive replicated messages to the cluster, be able to send any cluster message, mark any present message as consumed, run any job on the cluster, and also view/modify/create other users' jobs. Only cluster messages and internal qpid/MRG configuration is accessible to the remote attacker.
It was reported [1] that an attacker can gain access to qpidd as an anonymous user, even if the ANONYMOUS mechanism is disallowed.
A patch is available (https://issues.apache.org/jira/browse/QPID-6325) that addresses this vulnerability. The fix will be included in subsequent releases, but can be applied to 0.30 if desired.
[1]: http://seclists.org/bugtraq/2015/Jan/122
It was reported [1], [2] that Apache QPID would crash due to a NULL pointer dereference when a remote, authenticated user attempted to redeclare an existing exchange and add a new alternate exchange. This would result in a denial of service condition of the server. This was corrected upstream by r811188 [3].
[1] https://issues.apache.org/jira/browse/QPID-2080 [2] https://bugzilla.redhat.com/showbug.cgi?id=517751 [3] http://svn.apache.org/viewvc?revision=811188&view=revision
It was reported [1] that Apache QPID would crash when receiving data from a client that is not valid AMQP data, resulting in a shut down of the cluster rather than the client being disconnected. This was corrected upstream by r785788 [2].
[1] https://bugzilla.redhat.com/showbug.cgi?id=506580 [2] http://svn.apache.org/viewvc?revision=785788&view=revision