Florian Weimer of the Red Hat Product Security Team discovered that setting the federation_tag 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 federation_tag 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.
I claim that this is not actually a flaw but a useful feature. The behavior (as described above) is that a connection may be considered by the broker as a "federation link" as opposed to a client connection. Federation links are permitted to proxy the authenticated-id in messages. This is important as federated links carry messages from many other connections, each of which may be associated with different authenticated user ids. In a federated environment, the ingress broker for a particular message is responsible for authenticating the user-id field in the message. For proper security, there must then be established a chain of trust between interconnected brokers such that a downstream broker trusts the upstream broker to have done (or proxied) proper authentication. The chain of trust is established by using an ACL policy to control access to the "auth-proxy" capability. In other words, when a broker establishes a connection to another broker, the connecting broker must authenticate with an identity that has the right to create a proxying link. A malicious attacker with a modified client that attempts to spoof a federation link must be able to authenticate as a trusted upstream broker. It is actually a feature to be able to create proxying connections as a regular client (i.e. by providing the federation tag). It may be desirable for a client (e.g. a web server) to proxy multiple user ids over a single connection. Such a policy can be created as follows: group proxies <id1> <id2> ... acl allow proxies create link acl deny-log all create link
But from my understanding, this is not the case. A client can connect to the broker as a federation link, rather than as a client, with no authentication and no restriction whatsoever. I understand the need for federated links between brokers, but when Joe User can connect to the broker without authentication and execute jobs as any user, surely that means there needs to be something to restrict these federated links from being established (perhaps there is a policy on the broker already that says "accept only federated links from IP X" or something)?
(In reply to comment #4) > But from my understanding, this is not the case. A client can connect to > the broker as a federation link, rather than as a client, with no > authentication and no restriction whatsoever. Comment 3 describes how to place a restriction on which users can create federation links. > > I understand the need for federated links between brokers, but when Joe User > can connect to the broker without authentication and execute jobs as any > user, surely that means there needs to be something to restrict these > federated links from being established (perhaps there is a policy on the > broker already that says "accept only federated links from IP X" or > something)?
Created attachment 607797 [details] qpid-fedlink-acl.patch This patch treats a missing ACL as a denial for federation links. After this patch, users must configure an ACL which specify users which are permitted to establish federation links. Curiously, the current behavior is alluded to in the manual, which suggests to prevent guest users from creating federation links: """ Do not allow guest to access and log QMF management methods that could cause security breaches: group allUsers guest@QPID .... acl deny-log allUsers create link acl deny-log allUsers access method name=connect acl deny-log allUsers access method name=echo acl allow all all """ <http://qpid.apache.org/books/trunk/AMQP-Messaging-Broker-CPP-Book/html/chap-Messaging_User_Guide-Security.html#sect-Messaging_User_Guide-Authorization-Specifying_ACL_Permissions> However, this requirement is not reflected in our own manuals which describe how to configure authentication for products which use qpid-cpp-server.
Does the above mean that this is just a configuration issue (i.e. should we have the configuration set to default deny rather than default allow, more or less aligning the config with what our docs indicate)? And if that is the case, does this patch just enforce a default deny (so that a default deny config isn't required)?
It is a configuration issue in the sense that it could be fixed with configuration (enable the ACL module, make sure that you have an ACL which does not allow link creation). condor-qmf absolutely requires this, so we'd have to release some advisory for MRG. (ACL usage with condor-qmf is very rare, so most installations are affected.) It has the usual problem shared with all configuration-only security fixes: implementation in the field will be poor. I'm also not sure if denying link creation is sufficient. What happens if a user requests routing messages to a remote broker? Would this expose messages the user would not otherwise have access to? I can't find any separate ACL checks for route creation.
(In reply to comment #8) > I'm also not sure if denying link creation is sufficient. What happens if a > user requests routing messages to a remote broker? Would this expose > messages the user would not otherwise have access to? I can't find any > separate ACL checks for route creation. Denying link creation is sufficient. Routes are dependent on federation link creation. If there are no federation links, there will be no operational routes.
I'm of the opinion that a hard-coded default is probably the best bet, from a security perspective. I don't know, however, if it is best from an operational perspective (Matt or Ted would have to weigh in on that). Based on the above comment, we could have ACLs/hard-coded default to deny link creation and that would solve the problem. I guess the implementation of how to do that is the next question. I'm giving this the name CVE-2012-4446 as this is a flaw we will want to correct.
(In reply to comment #9) > Routes are dependent on federation link creation. If there are no > federation links, there will be no operational routes. What about push routes added with "qpid-route add route -s"? The target broker would have to perform the check, and it could be under the control of the attacker. This would not enable message spoofing, but could perhaps be used to get access to exchanges/queues to which the user would not normally have access to.
(In reply to comment #10) > I'm of the opinion that a hard-coded default is probably the best bet, from > a security perspective. I don't know, however, if it is best from an > operational perspective (Matt or Ted would have to weigh in on that). > > Based on the above comment, we could have ACLs/hard-coded default to deny > link creation and that would solve the problem. I guess the implementation > of how to do that is the next question. > > I'm giving this the name CVE-2012-4446 as this is a flaw we will want to > correct. I'm pro hard-coded default deny, or an extensible configuration mechanism so we can deny without editing RPM owned /etc/qpidd.conf.
A comment from Chuck Rolke (who can't access the BZ): Broker ACL already has a fastpath detection flag for which it scans the ACL file for PUBLISH EXCHANGE rules. The flag represents the presence of a publish exchange rule. I propose adding another flag that reflects the presence of CREATE LINK rules. This flag is tested in code just before the ACL authorize lookup. In pseudo code: function brokerCreateLink() if (aclLoaded) if (acl->createLinkFlag) if (acl->authorise(user, create, link, properties)) <create link allowed> else <create link denied - not authorized> endif else <create link denied - acl did not specify a create link rule> endif else <create link denied - acl module not loaded> endif end function Using release notes and decent log messages users whose link creation fails will be able to figure out what to do.
Chuck, please evaluate Florian's patch and also address this question: (In reply to comment #11) > (In reply to comment #9) > > Routes are dependent on federation link creation. If there are no > > federation links, there will be no operational routes. > > What about push routes added with "qpid-route add route -s"? The target > broker would have to perform the check, and it could be under the control of > the attacker. This would not enable message spoofing, but could perhaps be > used to get access to exchanges/queues to which the user would not normally > have access to.
(In reply to comment #12) > (In reply to comment #10) > > I'm of the opinion that a hard-coded default is probably the best bet, from > > a security perspective. I don't know, however, if it is best from an > > operational perspective (Matt or Ted would have to weigh in on that). > > > > Based on the above comment, we could have ACLs/hard-coded default to deny > > link creation and that would solve the problem. I guess the implementation > > of how to do that is the next question. > > > > I'm giving this the name CVE-2012-4446 as this is a flaw we will want to > > correct. > > I'm pro hard-coded default deny, or an extensible configuration mechanism so > we can deny without editing RPM owned /etc/qpidd.conf. Our plan, once we have the go-ahead, is to introduce the hard-coded default on qpid trunk. A shorter-term fix, one that introduces a default-shipped acl.conf, is being developed for downstream releases in the mean time.
Acknowledgements: This issue was discovered by Florian Weimer of the Red Hat Product Security Team.
This issue has been addressed in following products: MRG for RHEL-6 v.2 Via RHSA-2013:0562 https://rhn.redhat.com/errata/RHSA-2013-0562.html
This issue has been addressed in following products: MRG for RHEL-5 v. 2 Via RHSA-2013:0561 https://rhn.redhat.com/errata/RHSA-2013-0561.html
External References: https://issues.apache.org/jira/browse/QPID-4631
Created qpid-cpp tracking bugs for this issue Affects: fedora-all [bug 918804]