Bug 851355 - (CVE-2012-4446) CVE-2012-4446 qpid-cpp: qpid authentication bypass
CVE-2012-4446 qpid-cpp: qpid authentication bypass
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20130306,repor...
: Security
Depends On: 873413 873414 918804 986034
Blocks: 825141 851360
  Show dependency treegraph
 
Reported: 2012-08-23 18:08 EDT by Vincent Danen
Modified: 2014-12-10 09:00 EST (History)
16 users (show)

See Also:
Fixed In Version: qpid-cpp 0.23
Doc Type: Bug Fix
Doc Text:
It was found that the Apache Qpid daemon (qpidd) treated AMQP connections with the federation_tag attribute set as a broker-to-broker connection, rather than a client-to-server connection. This resulted in the source user ID of messages not being checked. A client that can establish an AMQP connection with the broker could use this flaw to bypass intended authentication. For Condor users, if condor-aviary is installed, this flaw could be used to submit jobs that would run as any user (except root, as Condor does not run jobs as root).
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-06 17:21:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
qpid-fedlink-acl.patch (798 bytes, patch)
2012-08-29 03:51 EDT, Florian Weimer
no flags Details | Diff

  None (edit)
Description Vincent Danen 2012-08-23 18:08:23 EDT
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.
Comment 3 Ted Ross 2012-08-24 14:57:58 EDT
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
Comment 4 Vincent Danen 2012-08-24 17:19:42 EDT
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)?
Comment 5 Ted Ross 2012-08-27 10:11:19 EDT
(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)?
Comment 6 Florian Weimer 2012-08-29 03:51:10 EDT
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.
Comment 7 Vincent Danen 2012-09-21 00:30:30 EDT
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)?
Comment 8 Florian Weimer 2012-09-21 07:50:30 EDT
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.
Comment 9 Ted Ross 2012-09-21 08:44:13 EDT
(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.
Comment 10 Vincent Danen 2012-09-24 17:42:37 EDT
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.
Comment 11 Florian Weimer 2012-09-26 11:15:18 EDT
(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.
Comment 12 Matthew Farrellee 2012-09-26 12:03:08 EDT
(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.
Comment 13 Justin Ross 2012-10-01 11:34:07 EDT
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.
Comment 15 Justin Ross 2012-11-05 13:38:04 EST
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.
Comment 16 Justin Ross 2012-11-05 13:39:54 EST
(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.
Comment 22 Murray McAllister 2013-02-26 02:49:59 EST
Acknowledgements:

This issue was discovered by Florian Weimer of the Red Hat Product Security Team.
Comment 23 errata-xmlrpc 2013-03-06 13:50:46 EST
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
Comment 24 errata-xmlrpc 2013-03-06 13:51:53 EST
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
Comment 25 Vincent Danen 2013-03-06 17:11:42 EST
External References:

https://issues.apache.org/jira/browse/QPID-4631
Comment 26 Vincent Danen 2013-03-06 17:13:11 EST
Created qpid-cpp tracking bugs for this issue

Affects: fedora-all [bug 918804]

Note You need to log in before you can comment on or make changes to this bug.