[Yahoo-eng-team] [Bug 1407105] Re: Password Change Doesn't Affirmatively Invalidate Sessions
** Changed in: horizon/kilo
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1407105
Title:
Password Change Doesn't Affirmatively Invalidate Sessions
Status in OpenStack Dashboard (Horizon):
Fix Released
Status in OpenStack Dashboard (Horizon) kilo series:
Fix Released
Status in OpenStack Identity (keystone):
Fix Released
Status in OpenStack Identity (keystone) icehouse series:
Fix Released
Status in OpenStack Identity (keystone) juno series:
Fix Released
Status in OpenStack Security Advisory:
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:
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
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
[Yahoo-eng-team] [Bug 1407105] Re: Password Change Doesn't Affirmatively Invalidate Sessions
** Also affects: horizon/kilo
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1407105
Title:
Password Change Doesn't Affirmatively Invalidate Sessions
Status in OpenStack Dashboard (Horizon):
Fix Released
Status in OpenStack Dashboard (Horizon) kilo series:
Fix Committed
Status in OpenStack Identity (keystone):
Fix Released
Status in OpenStack Identity (keystone) icehouse series:
Fix Released
Status in OpenStack Identity (keystone) juno series:
Fix Released
Status in OpenStack Security Advisory:
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:
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
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
[Yahoo-eng-team] [Bug 1407105] Re: Password Change Doesn't Affirmatively Invalidate Sessions
** Changed in: horizon
Status: Fix Committed => Fix Released
** Changed in: horizon
Milestone: None => liberty-3
--
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):
Fix Released
Status in Keystone:
Fix Released
Status in Keystone icehouse series:
Fix Released
Status in Keystone juno series:
Fix Released
Status in OpenStack Security Advisory:
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:
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
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
[Yahoo-eng-team] [Bug 1407105] Re: Password Change Doesn't Affirmatively Invalidate Sessions
** Also affects: keystone/icehouse
Importance: Undecided
Status: New
--
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:
New
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
[Yahoo-eng-team] [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
--
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
[Yahoo-eng-team] [Bug 1407105] Re: Password Change Doesn't Affirmatively Invalidate Sessions
** Changed in: keystone
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 Committed
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
[Yahoo-eng-team] [Bug 1407105] Re: Password Change Doesn't Affirmatively Invalidate Sessions
** 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
[Yahoo-eng-team] [Bug 1407105] Re: Password Change Doesn't Affirmatively Invalidate Sessions
** Also affects: keystone/juno
Importance: Undecided
Status: New
** Changed in: keystone/juno
Status: New = In Progress
** Changed in: keystone/juno
Importance: Undecided = Low
** Changed in: keystone/juno
Assignee: (unassigned) = Dolph Mathews (dolph)
** Changed in: keystone
Milestone: None = kilo-2
--
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 Committed
Status in Keystone juno series:
In Progress
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
[Yahoo-eng-team] [Bug 1407105] Re: Password Change Doesn't Affirmatively Invalidate Sessions
Given the overwhelming consensus that this isn't exploitable, I've
switched the bug to public and marked the security advisory task won't
fix so this can just be worked as a normal bug/hardening opportunity.
** Information type changed from Private Security to Public
** Changed in: ossa
Status: Incomplete = Won't Fix
--
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):
Incomplete
Status in OpenStack Identity (Keystone):
New
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
