Open Stack

Public facing services such as APIs and web-facing services such as Horizon
are critical to update, but don't forget everything within the cluster that
uses internal secure communications. Anything that could potentially use
OpenSSL is impacted and needs to have OpenSSL updated on it, services
restarted, and key material (both primary and secondary) and credentials
changed.  Services such as the following should all be restarted:

DB: MySQL, Postgres
MQ: Rabbit, Qpid
APIs: Likely Apache httpd, nginx, pound, etc
Keystone: Or Apache httpd, nginx, pound, etc
django/horizon: Or Apache httpd, nginx, pound, etc
glance-*
nova-*
cinder-*
libvirtd

"lsof | grep ssl | grep DEL" is your friend.  It will output any services
that may still have stale handles using the old library.

Nate





On Wed, Apr 9, 2014 at 3:29 PM, Greg C <agregc at gmail.com> wrote:

> I found that my openstack system was vulnerable by using the test found
> here:
> http://filippo.io/Heartbleed
>
> I'm running on Ubuntu12.04, and this is an older openstack system
> (folsom).  I fixed the vulnerability by updating package python-openssl and
> restarting apache (apt-get update, apt-get install python-openssl, service
> apache2 restart).  Test then returned "OK"
>
> Openstack runs on python, so naturally that's how it became vulnerable.
> Not strictly an "openstack component", but it can/will make you system
> vulnerable to heartbleed.
>
> There could be other places that need updates too, but at least there's
> that one.
>
>
> On Wed, Apr 9, 2014 at 3:46 AM, Thierry Carrez <thierry at openstack.org>wrote:
>
>> Aryeh Friedman wrote:
>> > What parts of openstack (if any) are vulnerable to heartbleed?
>>
>> OpenStack in itself is not vulnerable to heartbleed, however OpenStack
>> makes use of the host SSL library (libssl) and that one should be
>> properly patched.
>>
>> If you have a production deployment of OpenStack, you should consider
>> the SSL private keys for your SSL endpoints potentially compromised and
>> revoke / renew them (primary key material).
>>
>> Once you've done that, you should warn your users that passwords and
>> tokens used over that previously-flawed secure connection could have
>> been compromised and encourage them to change their own passwords and
>> expire existing tokens (secondary key material).
>>
>> Regards,
>>
>> --
>> Thierry Carrez (ttx)
>>
>> _______________________________________________
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>
>
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140409/43a476e6/attachment.html>