CVE-2018-1279

Red Hat 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.