© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
While I agree this is a bug (the logout call should include an explicit session destruction), I'm not particularly overwhelmed by its severity.
Remember that the default session store for Horizon stores data in a client cookie. If an attacker gets access to that, they've got complete access to everything a Horizon user can do. Keystone should probably invalidate those tokens on a password change (I don't know if it actually does), but that's not Horizon's concern. If it does invalidate those tokens, the old session stored by horizon becomes useless and this bug is invalid.
It looks like that might happen? I'm not familiar enough with the keystone codebase to know by inspection if that really is what's happening here:
https:/
In the case of a non-cookie based session backend, you are correct that a blocked redirect to the logout url will prevent the user from being logged out and the previous session will remain valid. An attack of this form requires an active MITM and the technical ability to do traffic analysis to look into the opaque TLS session and interrupt it at just the correct moment. You _might_ be able to do it based on size of response or response timing. This is particularly hard if the connection is using keepalive, pipelining, or spdy. Horizon pages tend to be relatively uniform in size and resources, so you don't have a lot of latitude there.
In any case "just blocking this one response" is non-trivial to the point that I don't expect that you can demonstrate it reliably against a properly configured server. An attacker who has MITM can block _all_ traffic to prevent both a password reset and this session logout thing, which is functionally similar.
Your point 2 is entirely beyond the scope of Horizon. If what you say is true, you need to take it up with the keystone team.
While I agree that this is a bug related to security, I'm tempted to vote that it is not one we need to keep private.