Bug 1428240 (CVE-2017-2637)

Summary:	CVE-2017-2637 rhosp-director:libvirtd is deployed with no authentication
Product:	[Other] Security Response	Reporter:	Summer Long <slong>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	unspecified	CC:	aortega, apevec, aschultz, athomas, ayoung, berrange, chrisw, cvsbot-xmlrpc, dbecker, eglynn, emacchi, gmollett, hbrock, jjoyce, josorior, jrusnack, jschluet, kbasil, lhh, lhinds, lpeer, markmc, mburns, morazi, owalsh, pmyers, rbryant, rcritten, rhel-osp-director-maint, sclewis, security-response-team, sgordon, shardy, slinaber, slong, tdecacqu
Target Milestone:	---	Keywords:	Security, Triaged
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:	A design flaw issue was found in the Red Hat OpenStack Platform director use of TripleO to enable libvirtd based live-migration. Libvirtd is deployed by default (by director) listening on 0.0.0.0 (all interfaces) with no-authentication or encryption. 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 possibly addresses that have been 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.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-06-21 00:07:30 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:	1428241, 1428590, 1428591, 1428592, 1428593
Bug Blocks:	1425413

Description Summer Long 2017-03-02 06:18:56 UTC

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

Comment 3 Daniel Berrangé 2017-03-07 12:11:46 UTC

(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.

Comment 4 Garth Mollett 2017-03-07 22:57:02 UTC

(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.

Comment 5 Ollie Walsh 2017-03-09 15:29:51 UTC

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

Comment 13 Summer Long 2017-03-29 23:00:18 UTC

Acknowledgments:

Name: David Gurtner (Red Hat)

Comment 30 errata-xmlrpc 2017-05-17 12:23:24 UTC

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

Comment 31 Garth Mollett 2017-05-17 20:35:31 UTC

Mitigation:

A KCS article with more details on this flaw is available at: https://access.redhat.com/solutions/3022771

Comment 32 errata-xmlrpc 2017-06-19 14:46:52 UTC

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

Comment 33 errata-xmlrpc 2017-06-20 12:25:53 UTC

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

Comment 34 errata-xmlrpc 2017-06-20 12:46:02 UTC

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

Comment 35 Stephen Gordon 2017-06-20 19:18:15 UTC

(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.