Bug 1661092 (CVE-2018-1279)

Summary:	CVE-2018-1279 rabbitmq-server: Deterministically generated cookie shared between all machines
Product:	[Other] Security Response	Reporter:	Sam Fowler <sfowler>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	unspecified	CC:	abhgupta, apevec, dajohnso, dbaker, dbecker, dclarizi, dmetzger, gblomqui, gmainwar, gmccullo, gtanzill, jeckersb, jfrey, jhardy, jjoyce, jlaska, jokerman, jprause, jschluet, kdixon, lhh, lpeer, mburns, obarenbo, plemenko, roliveri, sclewis, simaishi, slinaber, sthangav, trankin
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
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.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-12-23 00:27:37 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1661361, 1661362, 1662771, 1662772, 1662773
Bug Blocks:	1661095

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:

https://pivotal.io/security/cve-2018-1279

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:

https://bugzilla.novell.com/show_bug.cgi?id=1119372

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

Statement:

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.

OpenStack:
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):

https://access.redhat.com/security/cve/cve-2018-1279