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
Unclear if this is strictly limited to the commercial version of RabbitMQ produced by Pivotal Software and deployed in PCF.
SUSE bug: https://bugzilla.novell.com/show_bug.cgi?id=1119372
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.
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.
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