Bug 1059504 (CVE-2013-6491)

Summary:	CVE-2013-6491 Openstack nova: qpid SSL configuration
Product:	[Other] Security Response	Reporter:	Garth Mollett <gmollett>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	aortega, apevec, ayoung, chrisw, dallan, gkotton, iheim, lhh, markmc, ndipanov, rbryant, rcritten, rhos-maint, sclewis, yeylon
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-04-15 00:29:54 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:	996766
Bug Blocks:	1023240

Description Garth Mollett 2014-01-30 01:46:01 UTC

JuanFra Rodriguez Cardoso discovered that nova was not correctly enabling SSL parameters when using the qpid client. Enabling "qpid_protocol = ssl" in nova.conf would not result in SSL being used to commnicate to qpid. If qpid was not configured to enforce SSL this could lead to sensitive information being sent in the clear.

Comment 1 Rob Crittenden 2014-01-30 02:20:53 UTC

I don't think the qpid connection is actually successful, even with require_encryption off, so no data actually flows. Did you do any network tracing to confirm that data goes over the wire unencrypted?

Comment 2 Garth Mollett 2014-01-30 03:54:08 UTC

Yes I did. It made the connection and worked as normal (with no ssl) even though
ssl was enabled in the nova.conf.

After applying the patch and restarting nova-compute it fails to connect to qpid
(as I had not setup certificate etc.. in qpid).

Comment 3 Garth Mollett 2014-01-30 04:46:56 UTC

So looking at the code. The Connection class in qpid.messaging has no
attribute named "protocol". So in the nova qpid rpc implementation without the
patch, all that is happening is a new str attribute called "protocol" is getting
created and is then ignored.

A regular tcp connection is made as the transport attribute is still set to
'tcp' which is the default.

Comment 4 Garth Mollett 2014-01-30 04:59:50 UTC

Upstream bug report:

https://bugs.launchpad.net/oslo/+bug/1158807

Comment 5 Rob Crittenden 2014-01-30 14:17:34 UTC

Ok, I see what you're saying. If you just set protocol to ssl it is basically a no-op. A user may not know to change the port as well.

Comment 6 errata-xmlrpc 2014-01-30 20:00:41 UTC

This issue has been addressed in following products:

  OpenStack 3 for RHEL 6

Via RHSA-2014:0112 https://rhn.redhat.com/errata/RHSA-2014-0112.html