I’ve been working with the Havanna release of OpenStack the last couple of days and ran across a default setting that should be avoided in any deployment: using cookies as the session backend.

The source of the problems has been known at least since October 2013  in Django and other frameworks: clear-text client-side session management.
There is even OSVDB entry and Threatpost covered it in an article.

Background

Horizon or the OpenStack dashboard is based on a stack of Django, D3, Hogan.js and jQuery.

Both the OpenStack and Django documentation reflect the issue:

• Ubuntu 12.04.2 LTS

Uses memcache so it is OK

for i in `dpkg -L openstack-dashboard|egrep "local_settings|settings"`; do grep -iH SESSION_ENGINE $i; done
 /usr/share/openstack-dashboard/settings.py:SESSION_ENGINE = 'django.contrib.sessions.backends.cache'
 /usr/share/openstack-dashboard/openstack_dashboard/settings.py:SESSION_ENGINE = 'django.contrib.sessions.backends.cache'

• Ubuntu 13.10

Uses signed cookies so the vulnerability is present

for i in `dpkg -L openstack-dashboard|egrep “local_settings|settings”`; do grep -iH SESSION_ENGINE $i; done
/usr/share/openstack-dashboard/openstack_dashboard/settings.py:SESSION_ENGINE = ‘django.contrib.sessions.backends.signed_cookies’
/usr/share/openstack-dashboard/settings.py:SESSION_ENGINE = ‘django.contrib.sessions.backends.signed_cookies‘

• CentOS 6.5

Uses signed cookies so the vulnerability is present

for i in `rpm -ql openstack-dashboard.noarch| egrep “local_settings|settings”|egrep “.py$”`; do grep -iH SESSION_ENGINE $i; done
/usr/share/openstack-dashboard/openstack_dashboard/settings.py:SESSION_ENGINE = ‘django.contrib.sessions.backends.signed_cookies‘

The Impact

If someone is able to find, steal or even sniff a user’s cookie they can log into your OpenStack as that user event if the user has logged out.

Solution

If possible avoid using cookies or any other client-side session managemet and configure it to use server-side solution, like memcache.