session ID reusable?

[Jeremy Stanley]

Reported via private E-mail from Anass ANNOUR:

I had tested to reply the session ID and the token to a local environnent between to distinct IP, and it worked perfectly.

[Jeremy Stanley (fungi)]

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

[Lin Hua Cheng (lin-hua-cheng)]

The screenshot shows keystone token, is this supposed to be for Keystone?

[Morgan Fainberg (mdrnstm)]

Tokens are in-fact bearer tokens, meaning that if someone gets a valid token it conveys the authorization of the user it was issued for.

I'm not clear on the reported bug/security vulnerability. The token ids all look different, it is possible to use a token over and over - this is a design requirement for the way OpenStack works today since nova will act upon glance and cinder on behalf of the user.

There are initiatives to make this better. But it is well known and documented tokens are bearer tokens.

[ANNOUR (anass-annour)]

Yes we can re-use the token during its TTL ( 1 hour)
I had generated many tokens for the same user, after that i used anyone of them (during one hour). this means we can have many reusable tokens for the same user in the same time.
This situation can be dangerous in the case we have an inside threat.
I think to mitigate the threat, we can send tokens over an encrypted channel but, it may be hard to implement, using also firewall rules can help ( but it may impact Openstack API usage)
I think someone who has deep experience on this issue ( using token between services) can give us more informations on that.

[ANNOUR (anass-annour)]

The same issue occurs in the tokens generated by keystone and the session ID generated by Horizon.

[Morgan Fainberg (mdrnstm)]

This is currently the design of tokens. You can revoke the tokens or have an event (such as a password change) revoke tokens. This is a long-running design of how tokens work. Short of changing the entire way OpenStack handles authorization (not out of the picture but hard to do), this is a known.

It is recommended that SSL is used with bearer tokens. It is possible (with some work) to add token binding in, but this has similar issues for inter-service work (e.g. nova acting with glance on the user's behalf).

We *could* potentially use the audit ids to revoke tokens in revocation events for the whole chain on logout, but it would be problematic when you have long running tasks.

This is not really a security concern that is outside of the "known/documented" way OpenStack works.

At this point, it isn't really feasible to fix this (I'd classify as "wont fix") - tokens have short TTLs for a reason. We can look into how auth works in OpenStack as a feature and work towards changing it to close this gap. This is not a small initiative and not a bug, more of "how this was all designed".

[Dolph Mathews (dolph)]

ANNOUR:

"This situation can be dangerous in the case we have an inside threat." If you're referring to a specific attack vector here, it's not clear to me what it is?

"I think to mitigate the threat, we can send tokens over an encrypted channel but, it may be hard to implement" There's a big red box on the token format comparison docs that indicates that all formats are bearer tokens and that they must be protected as such (HTTPS, etc): http://docs.openstack.org/developer/keystone/configuration.html#token-provider

I'd love to see OAuth (or some other signature-based authentication method) implemented OpenStack-wide, but as Morgan suggested, it's a tall mountain to climb coming from bearer tokens. We've had summit sessions on the topic in the past and the interest in moving away from bearer tokens hasn't exactly been overwhelming ... yet.

[Dolph Mathews (dolph)]

I'm also not totally clear on the title of the bug, and the reference to "sessions": is a "session ID" a bearer token?

[Jeremy Stanley (fungi)]

When Anass originally sent me this bug report via E-mail, I believe he was discussing reusability both of Horizon session IDs and Keystone tokens. At the time he may not have realized the reports would be farmed out to developers on different components of OpenStack and so had not optimized his report accordingly. Since I'm unfortunately not particularly familiar with the provenance of the dataset he attached and because of the vagueness of his original E-mail, I mistakenly opened this one under Horizon until their developers pointed out that the attachment was a database query of Keystone tokens.

[Guang Yee (guang-yee)]

Is this related to Bug 1447676?

I presume the "insider threat" is referring to someone who has read access to the Keystone database?

[Morgan Fainberg (mdrnstm)]

@Guang,

Possibly.

[ANNOUR (anass-annour)]

The insider threat refers to someone inside the network, not only the one who has a read access to the database ( as discussed earlier Bug 1447676 , if an attacker access the keystone database, it s game-over for the Openstack security).

The flexibility of openstack, allows its deployment in large scale (surely in separate servers), means all communications between openstack's components are in clear text.

Short description of the issue : Management of token (also session ID in horizon) doesn't verify the sender of the token ( trusted or malicious IP) which make tokens (and session ID) reusable (during its TTL) by malicious person.

[Dolph Mathews (dolph)]

The short description at the end of comment #13 is basically the definition of a bearer token.

This is a well covered topic ( https://www.google.com/search?q=openstack+keystone+bearer+tokens ) , so I'd suggest this issue be opened publicly. I don't really think an OSSN needs to be written given the existing coverage in our own docs (see comment #8 for example), ongoing discussions to introduce signature-based alternatives (as recent as the Kilo summit https://etherpad.openstack.org/p/kilo-keystone-authorization and at least as far back as Havana, in terms of design summit coverage https://etherpad.openstack.org/p/havana-saml-oauth-scim ), and existing solutions like token binding (implemented way back in 2013.2!):

  https://blueprints.launchpad.net/keystone/+spec/authentication-tied-to-token

[Morgan Fainberg (mdrnstm)]

So while I agree bearer tokens are not optimal this bug is not easily fixable. This bug is reporting a known concern with the entire design of openstack's authoriZation model. There has not been a large interest in fixing this by the community and it is a tall order to move away from bearer tokens

This bug is something that I am going to say is "won't fix" from the Keystone side as a "bug"

To change to something besides bearer tokens is going to require a slot of redesign of how everything across OpenStack works. I am not willing to classify this as a "bug" - this is an enhancement. To make this enhancement a reality, we need a significant amount of buy in *and* will require changing how every user interacts with every api in OpenStack.

This bug is simply saying that the design choices made a long time ago in fact have the documented issues of bearer tokens. The "insider threat" is solved via non-persistent tokens and SSL termination of the endpoints. If a user is compromised a change of password will revoke tokens. If a specific token is compromised, that token can be revoked.

Tokens have a fixed TTL to help mitigate this issue when coupled with non-persistent tokens and proper SSL termination.

As stated in my previous comments, we are not opposed to the change away from bearer tokens - but it is a significant overhead / wholesale change of authorization model.

[Morgan Fainberg (mdrnstm)]

Dolph: agreed. This is not private - and at best is an RFE. OSSN or OSSA Is not needed.

[Jeremy Stanley (fungi)]

Based on discussion above, I've switched this report to public, marked it as potential security hardening in case someone decides to work on it in the future, and set the security advisory task to won't fix indicating it's not a report for which the vulnerability management team will be issuing one. This is either category B2, D or E in our incident reporting taxonomy, most probably E. http://security.openstack.org/vmt-process.html#incident-report-taxonomy

[Guang Yee (guang-yee)]

Read the fantastical OpenStack Security Guide :)

http://docs.openstack.org/security-guide/content/

[Dolph Mathews (dolph)]

Z! poor architecture / design, with (some) security implications, e.g., strengthening opportunities

[Launchpad Janitor (janitor)]

[Expired for Keystone because there has been no activity for 60 days.]