← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1407105] Re: Password Change Doesn't Affirmatively Invalidate Sessions

 

** Changed in: keystone/icehouse
       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 icehouse series:
  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