** Changed in: keystone/juno
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1407105
Title:
Password Change Doesn't Affirmatively Invalidate Sessions
Status in OpenStack Dashboard (Horizon):
Triaged
Status in OpenStack Identity (Keystone):
Fix Released
Status in Keystone juno series:
Fix Released
Status in OpenStack Security Advisories:
Won't Fix
Bug description:
This issue is being treated as a potential security risk under
embargo. Please do not make any public mention of embargoed (private)
security vulnerabilities before their coordinated publication by the
OpenStack Vulnerability Management Team in the form of an official
OpenStack Security Advisory. This includes discussion of the bug or
associated fixes in public forums such as mailing lists, code review
systems and bug trackers. Please also avoid private disclosure to
other individuals not already approved for access to this information,
and provide this same reminder to those who are made aware of the
issue prior to publication. All discussion should remain confined to
this private bug report, and any proposed fixes should be added as to
the bug as attachments.
The password change dialog at /horizon/settings/password/ contains the
following code:
<code>
if user_is_editable:
try:
api.keystone.user_update_own_password(request,
data['current_password'],
data['new_password'])
response = http.HttpResponseRedirect(settings.LOGOUT_URL)
msg = _("Password changed. Please log in again to continue.")
utils.add_logout_reason(request, response, msg)
return response
except Exception:
exceptions.handle(request,
_('Unable to change password.'))
return False
else:
messages.error(request, _('Changing password is not supported.'))
return False
</code>
There are at least two security concerns here:
1) Logout is done by means of an HTTP redirect. Let's say Eve, as MitM, gets
ahold of Alice's token somehow. Alice is worried this may have happened, so
she changes her password. If Eve suspects that the request is a
password-change request (which is the most Eve can do, because we're running
over HTTPS, right? Right!?), then it's a simple matter to block the redirect
from ever reaching the client, or the redirect request from hitting the server.
From Alice's PoV, something weird happened, but her new password works, so
she's not bothered. Meanwhile, Alice's old login ticket continues to work.
2) Part of the purpose of changing a password is generally to block those who
might already have the password from continuing to use it. A password change
should trigger (insofar as is possible) a purging of all active logins/tokens
for that user. That does not happen here.
Frankly, I'm not the least bit sure if I've thought of the worst-case
scenario(s) for point #1. It just strikes me as very strange not to
aggressively/proactively kill the ticket/token(s), instead relying on
the client to do so. Feel free to apply minds smarter and more
devious than my own!
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1407105/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
