Bug 1661092 (CVE-2018-1279) - CVE-2018-1279 rabbitmq-server: Deterministically generated cookie shared between all machines
Summary: CVE-2018-1279 rabbitmq-server: Deterministically generated cookie shared betw...
Alias: CVE-2018-1279
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1661361 1661362 1662771 1662772 1662773
Blocks: 1661095
TreeView+ depends on / blocked
Reported: 2018-12-20 06:16 UTC by Sam Fowler
Modified: 2021-02-16 22:38 UTC (History)
31 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
RabbitMQ, versions up to and including 3.7.9, use an insecure method for generating authentication cookies when configuring clustered operations. It is possible to determine the cookie given adequate network topology information. Using the default cookie generated by RabbitMQ when forming a RabbitMQ cluster may lead to privileged access if the cookie is determined.
Clone Of:
Last Closed: 2020-12-23 00:27:37 UTC

Attachments (Terms of Use)

Description Sam Fowler 2018-12-20 06:16:39 UTC
Pivotal RabbitMQ for PCF, all versions, uses a deterministically generated cookie that is shared between all machines when configured in a multi-tenant cluster. A remote attacker who can gain information about the network topology can guess this cookie and, if they have access to the right ports on any server in the MQ cluster can use this cookie to gain full control over the entire cluster.

External Reference:


Comment 1 Sam Fowler 2018-12-20 06:18:45 UTC
Unclear if this is strictly limited to the commercial version of RabbitMQ produced by Pivotal Software and deployed in PCF.

Comment 2 Sam Fowler 2018-12-20 06:19:06 UTC
SUSE bug:


Comment 8 Borja Tarraso 2019-01-11 14:19:11 UTC
In Tower we do not use the programmatic cookie generation that gives rise to this vulnerability. Instead we use cookiemonster. So this issue does not affect Ansible Tower.

Comment 13 Eric Christensen 2019-01-15 15:50:39 UTC

OpenShift Online:
RabbitMQ is only used by the Ansible Tower, which is not a standard part of the OpenShift product, however is deployed as a management tool.

This is set as deferred as it has no impact to customers and is not deployed in a clustered configuration. A cluster using an Erlang-generated cookie would be required for cookie guessing to provide and environmental leverage.

For RHOSP10+, the rabbit cookie is set to a random string during deployment, rather than relying on Erlang to generate the cookie, if the cookie has not been overridden in the deployment configuration. In either case, this avoids the predictable Erlang cookie generation highlighted by this flaw, meaning RHOSP10+ is not vulnerable. Further mitigating the flaw, is the fact that RabbitMQ, in an OpenStack context, is deployed to the admin network and as such should only be accessible to OpenStack services, not public users via an external network.

For RHOSP8+9, when deployed with Director (TripleO), the RabbitMQ salt is initialized via the Heat RandomString function, also bypassing this vulnerability. RHOSP8+9 however did not use Director as the default deployment mechanism. When installing RHOSP manually in these versions, our installation documentation does not provide guidance for configuring clustered RabbitMQ. It is safe to assume that some customers may have this configured in an insecure way, despite the fact that we would not have told them how to install and configure a cluster in a vulnerable way.

Ansible Tower:
In Tower we do not use the programmatic cookie generation that gives rise to this vulnerability. Instead we use cookiemonster. So this issue does not affect Ansible Tower.

CloudForms (CFME):
RabbitMQ shipped with CloudForms is exclusively used by Ansible Tower. Since Ansible Tower is not vulnerable, due to the reasons described above, then CloudForms isn't, as well.

Comment 14 Product Security DevOps Team 2020-12-23 00:27:37 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):


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