Red Hat Bugzilla – Bug 1428240
CVE-2017-2637 rhosp-director:libvirtd is deployed with no authentication
Last modified: 2017-06-20 20:07:30 EDT
OSP director was found to deploy libvirtd listening on 0.0.0.0 with no-authentication and in some cases no network ACL's. Anyone able to make a tcp connection to any compute host IP address, including 127.0.0.1, other loopback interface addresses or in some cases even those exposed beyond the management interface, could use this to open a virsh session to the libvirtd instance and gain control of virtual machine instances or possibly take over the host. External References: https://access.redhat.com/solutions/3022771 https://wiki.openstack.org/wiki/OSSN/OSSN-0007
(In reply to Summer Long from comment #0) > OSP director was found to deploy libvirtd listening on 0.0.0.0 with > no-authentication and in some cases no network ACL's. Anyone able to make a > tcp connection to any compute host IP address, including those exposed > beyond the management interface, could use this to open a virsh session to > the libvirtd instance and gain control of virtual machine instances or > possibly take over the host. It is not merely remote attackers that are a problem. Local unprivileged processes can connect to 127.0.0.1, avoiding any firewalls, and use this to elevate their privileges to root. ie local privilege escalation even if a firewall is present.
(In reply to Daniel Berrange from comment #3) > (In reply to Summer Long from comment #0) > > OSP director was found to deploy libvirtd listening on 0.0.0.0 with > > no-authentication and in some cases no network ACL's. Anyone able to make a > > tcp connection to any compute host IP address, including those exposed > > beyond the management interface, could use this to open a virsh session to > > the libvirtd instance and gain control of virtual machine instances or > > possibly take over the host. > > It is not merely remote attackers that are a problem. Local unprivileged > processes can connect to 127.0.0.1, avoiding any firewalls, and use this to > elevate their privileges to root. ie local privilege escalation even if a > firewall is present. Thanks Dan. I modified the text to add "(including 127.0.0.1 or other loopback interface addresses)". I think that should make the local escalation path clear.
Dan raise this issue for the upstream docs long ago https://bugs.launchpad.net/openstack-manuals/+bug/1287194 Which resulted in https://wiki.openstack.org/wiki/OSSN/OSSN-0007
Acknowledgments: Name: David Gurtner (Red Hat)
This issue has been addressed in the following products: Red Hat OpenStack Platform 10.0 (Newton) Via RHSA-2017:1242 https://access.redhat.com/errata/RHSA-2017:1242
Mitigation: A KCS article with more details on this flaw is available at: https://access.redhat.com/solutions/3022771
This issue has been addressed in the following products: Red Hat OpenStack Platform 9.0 (Mitaka) director Via RHSA-2017:1504 https://access.redhat.com/errata/RHSA-2017:1504
This issue has been addressed in the following products: Red Hat Enterprise Linux OpenStack Platform director 7.0 for RHEL 7 Via RHSA-2017:1537 https://access.redhat.com/errata/RHSA-2017:1537
This issue has been addressed in the following products: Red Hat OpenStack Platform 8.0 (Liberty) director Via RHSA-2017:1546 https://access.redhat.com/errata/RHSA-2017:1546
(In reply to Garth Mollett from comment #31) > Mitigation: > > A KCS article with more details on this flaw is available at: > https://access.redhat.com/solutions/3022771 I've updated the article to reflect that the relevant erratum have been released for Red Hat OpenStack Platform 7, 8, 9.