Bug 996766 - CVE-2013-6491: Setting Qpid SSL protocol sets wrong variable [openstack-3]
CVE-2013-6491: Setting Qpid SSL protocol sets wrong variable [openstack-3]
Status: CLOSED ERRATA
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-nova (Show other bugs)
3.0
Unspecified Unspecified
high Severity high
: z4
: 3.0
Assigned To: Xavier Queralt
Omri Hochman
: Security, SecurityTracking, Triaged, ZStream
Depends On:
Blocks: 1021536 1021537 1055616 CVE-2013-6491
  Show dependency treegraph
 
Reported: 2013-08-13 18:11 EDT by Rob Crittenden
Modified: 2016-04-26 15:55 EDT (History)
11 users (show)

See Also:
Fixed In Version: openstack-nova-2013.1.4-2.el6ost
Doc Type: Bug Fix
Doc Text:
By default, Qpid uses TCP as a connection transport instead of connection protocol. Previously, the procedure for enabling SSL in Qpid connections, 'qpid_protocol = ssl' in /etc/glance/glance-api.conf, set the connection protocol. However, the python-qpid client expects a connection transport type. The mismatch prevented Qpid from actually establishing an SSL connection. With this release, the 'qpid_protocol = ssl' setting now enables SSL for the connection transport instead of connection protocol. As such, Qpid can now successfully establish SSL connections.
Story Points: ---
Clone Of:
: 1021536 1021537 (view as bug list)
Environment:
Last Closed: 2014-01-30 14:59:39 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1158807 None None None Never
OpenStack gerrit 47574 None None None Never

  None (edit)
Description Rob Crittenden 2013-08-13 18:11:44 EDT
Description of problem:

Cloned from upstream bug https://bugs.launchpad.net/oslo/+bug/1158807

By default, TCP is used as transport for QPID connections. If you like to enable SSL, there is a flat 'qpid_protocol = ssl' available in nova.conf. However, python-qpid client is awaiting transport type instead of protocol. It seems to be a bug:

Solution: (https://github.com/openstack/nova/blob/master/nova/openstack/common/rpc/impl_qpid.py#L323)

WRONG: self.connection.protocol = self.conf.qpid_protocol
CORRECT: self.connection.transport = self.conf.qpid_protocol

Regards,
JuanFra.

Version-Release number of selected component (if applicable):

python-nova-2013.1.2-4.el6ost.noarch
Comment 1 Jakub Ruzicka 2013-09-09 12:29:37 EDT
This is a nova bug, not novaclient.
Comment 9 Omri Hochman 2014-01-26 09:28:47 EST
I'm using : python-nova-2013.1.4-4.el6ost.noarch (from puddle: 2014-01-22.1)

The fix from the solution:   (https://github.com/openstack/nova/blob/master/nova/openstack/common/rpc/impl_qpid.py#L323)  

Doesn't seems to match the current code under:
/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/impl_qpid.py

solution: 
---------
      "auto-delete": True,
                    },
                },
            }
            if node_opts:
                addr_opts["node"]["x-declare"].update(node_opts)

            self.address = "%s ; %s" % (node_name, jsonutils.dumps(addr_opts))
        elif conf.qpid_topology_version == 2:
            self.address = node_name
        else:
            raise_invalid_topology_version()

        self.reconnect(session)

    def reconnect(self, session):


current code: 
-------------
               "auto-delete": True,
                },
            },
        }
        if node_opts:
            addr_opts["node"]["x-declare"].update(node_opts)

        self.address = "%s ; %s" % (node_name, jsonutils.dumps(addr_opts))

        self.reconnect(session)

    def reconnect(self, session):
        """Re-establish the Sender after a reconnection"""
        self.sender = session.sender(self.address)


and please elaborate steps to verify.
Comment 10 Xavier Queralt 2014-01-27 04:03:52 EST
(In reply to Omri Hochman from comment #9)
> I'm using : python-nova-2013.1.4-4.el6ost.noarch (from puddle: 2014-01-22.1)
> 
> The fix from the solution:  
> (https://github.com/openstack/nova/blob/master/nova/openstack/common/rpc/
> impl_qpid.py#L323)  
> 
> Doesn't seems to match the current code under:
> /usr/lib/python2.6/site-packages/nova/openstack/common/rpc/impl_qpid.py
> 
> solution: 
> ---------
>       "auto-delete": True,
>                     },
>                 },
>             }
>             if node_opts:
>                 addr_opts["node"]["x-declare"].update(node_opts)
> 
>             self.address = "%s ; %s" % (node_name,
> jsonutils.dumps(addr_opts))
>         elif conf.qpid_topology_version == 2:
>             self.address = node_name
>         else:
>             raise_invalid_topology_version()
> 
>         self.reconnect(session)
> 
>     def reconnect(self, session):
> 
> 
> current code: 
> -------------
>                "auto-delete": True,
>                 },
>             },
>         }
>         if node_opts:
>             addr_opts["node"]["x-declare"].update(node_opts)
> 
>         self.address = "%s ; %s" % (node_name, jsonutils.dumps(addr_opts))
> 
>         self.reconnect(session)
> 
>     def reconnect(self, session):
>         """Re-establish the Sender after a reconnection"""
>         self.sender = session.sender(self.address)
> 
> 
> and please elaborate steps to verify.

Note that you're checking it against icehosue but this BZ is for the grizzly branch. You can find the patch in the external trackers section (https://review.openstack.org/47574) and it has nothing to do with the code you quote.

To test this one should change qpid to use SSL, set in nova.conf qpid_protocol=ssl and restart all the nova services.

Take into account that the other components' configuration must be updated too and that not all the components decided to backport this patch (I think it is missing only in 3.0 cinder) which means that not all of them will be able to use qpid with ssl.
Comment 11 Omri Hochman 2014-01-27 05:23:07 EST
I checked with puddle 2014-01-22.1 it's latest grizzly not icehouse: http://download.lab.bos.redhat.com/rel-eng/OpenStack/Grizzly/2014-01-22.1/puddle.repo

Well I've tried to set nova.conf with qpid_protocol=ssl and restart nova services then run nova cli commands-> I'm getting ERROR: [Errno 111] Connection refused.  

I've tried to set some other .conf files to work with ssl but maybe I'm missing something - How can I verify that this patch is actually in side the code in grizzly ? I think that will be the verification in this case.
Comment 12 Xavier Queralt 2014-01-27 05:58:39 EST
(In reply to Omri Hochman from comment #11)
> I checked with puddle 2014-01-22.1 it's latest grizzly not icehouse:
> http://download.lab.bos.redhat.com/rel-eng/OpenStack/Grizzly/2014-01-22.1/
> puddle.repo

The link to github pointed to master (a.k.a. Icehouse), that's why the code differs from what you can find packaged in Grizzly.

> 
> Well I've tried to set nova.conf with qpid_protocol=ssl and restart nova
> services then run nova cli commands-> I'm getting ERROR: [Errno 111]
> Connection refused.  
> 

For this to work you must configure QPID to use ssl too. I can't point you to any documentation on how to configure that right now but 

> I've tried to set some other .conf files to work with ssl but maybe I'm
> missing something - How can I verify that this patch is actually in side the
> code in grizzly ? I think that will be the verification in this case.

To verify that the patch has been applied you must check the line 370 of the file nova/openstack/common/rpc/impl_qpid.py, there instead of setting the attribute self.connection.protocol it should be setting self.connection.transport (see the patches in the external trackers section for more details).
Comment 13 Omri Hochman 2014-01-27 07:54:08 EST
Verified with  python-nova-2013.1.4-4.el6ost.noarch (puddle 2014-01-22.1)

The fix is in the code:
----------------------- 
self.connection.transport = self.conf.qpid_protocol 
(In line 370 :/usr/lib/python2.6/sitepackages/nova/openstack/common/rpc/impl_qpid.py)
Comment 16 errata-xmlrpc 2014-01-30 14:59:39 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

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

Note You need to log in before you can comment on or make changes to this bug.