| 2016-04-05 16:24:12 |
Tim Burke |
bug |
|
|
added bug |
| 2016-04-05 20:59:17 |
Tristan Cacqueray |
bug task added |
|
ossa |
|
| 2016-04-05 20:59:29 |
Tristan Cacqueray |
ossa: status |
New |
Incomplete |
|
| 2016-04-05 20:59:54 |
Tristan Cacqueray |
description |
Ordinarily, during a keystone-authenticated swift3 request,
* the client talks to a swift proxy-server, sending a request with
an Authorization header that includes a credential identifier and
signature;
* swift3 (in the proxy-server's pipeline) recognizes that this is
a S3 request, normalizes the request information to be the same
format as was used in the signature, and includes it in the WSGI
environment;
* s3_token picks up the normalized request, credential identifier,
and user-provided signature and sends them all to keystone;
* keystone's s3 extension uses the credential identifier to look up
the credential's secret, signs the normalized request, and
compares the user-provided signature to the expected one. If they
match, a fresh project-scoped token is issued; otherwise a 401 is
returned.
* s3_token either bubbles up the 401 response or puts the token and
tenant information into the WSGI environment so swift3 and
auth_token may continue handling the request.
Given knowledge of the HTTP method, path, and headers of a valid past
request, an attacker can bypass swift and obtain a project-scoped
token directly from keystone. This may be done well after the initial
request (and resulting token) have expired. The new token may be used
to access any service for which the original user is authorized.
Proposed solution:
Have the s3 extension in keystone verify that the request came from
the s3_token middleware. This may be done via either a service token
(similar to what's done in keystonemiddleware's auth_token middleware)
or a rotating pre-shared key (similar to what's done in swift's
tempurl middleware).
Alternative solutions:
Have the s3 extension only enabled in the v2.0 admin pipeline,
remove it from the v3 pipeline, and expose the v2.0 admin endpoint
only on internal networks. With the convergence of the admin and
public pipelines in v3, this seems unlikely to provide a long-term
solution. However, it may be a useful mitigation for deployments
that cannot quickly upgrade.
Have the s3 extension parse the normalized request, find the
timestamp, and reject requests with a timestamp more than 5 minutes
off from the server's time. This conflates keystone's responsibility
(authentication) with that of swift3 (authorization) and leads to
duplicated efforts.
Additional mitigation:
Require users to change their S3/EC2 credentials regularly.
(Note that while this is similar to bug #1561199, the two bugs cover
separate issues. 1561199 involves inter-middleware communication
within a single WSGI pipeline. This bug involves the communication
between separate services.) |
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 to the bug as attachments.
--
Ordinarily, during a keystone-authenticated swift3 request,
* the client talks to a swift proxy-server, sending a request with
an Authorization header that includes a credential identifier and
signature;
* swift3 (in the proxy-server's pipeline) recognizes that this is
a S3 request, normalizes the request information to be the same
format as was used in the signature, and includes it in the WSGI
environment;
* s3_token picks up the normalized request, credential identifier,
and user-provided signature and sends them all to keystone;
* keystone's s3 extension uses the credential identifier to look up
the credential's secret, signs the normalized request, and
compares the user-provided signature to the expected one. If they
match, a fresh project-scoped token is issued; otherwise a 401 is
returned.
* s3_token either bubbles up the 401 response or puts the token and
tenant information into the WSGI environment so swift3 and
auth_token may continue handling the request.
Given knowledge of the HTTP method, path, and headers of a valid past
request, an attacker can bypass swift and obtain a project-scoped
token directly from keystone. This may be done well after the initial
request (and resulting token) have expired. The new token may be used
to access any service for which the original user is authorized.
Proposed solution:
Have the s3 extension in keystone verify that the request came from
the s3_token middleware. This may be done via either a service token
(similar to what's done in keystonemiddleware's auth_token middleware)
or a rotating pre-shared key (similar to what's done in swift's
tempurl middleware).
Alternative solutions:
Have the s3 extension only enabled in the v2.0 admin pipeline,
remove it from the v3 pipeline, and expose the v2.0 admin endpoint
only on internal networks. With the convergence of the admin and
public pipelines in v3, this seems unlikely to provide a long-term
solution. However, it may be a useful mitigation for deployments
that cannot quickly upgrade.
Have the s3 extension parse the normalized request, find the
timestamp, and reject requests with a timestamp more than 5 minutes
off from the server's time. This conflates keystone's responsibility
(authentication) with that of swift3 (authorization) and leads to
duplicated efforts.
Additional mitigation:
Require users to change their S3/EC2 credentials regularly.
(Note that while this is similar to bug #1561199, the two bugs cover
separate issues. 1561199 involves inter-middleware communication
within a single WSGI pipeline. This bug involves the communication
between separate services.) |
|
| 2016-04-05 21:01:27 |
Tristan Cacqueray |
bug |
|
|
added subscriber Keystone Core security contacts |
| 2016-04-12 15:18:32 |
Dolph Mathews |
bug |
|
|
added subscriber David Stanek |
| 2016-05-30 18:10:55 |
Tristan Cacqueray |
bug |
|
|
added subscriber Swift Core security contacts |
| 2016-08-29 09:12:24 |
Donagh McCabe |
bug |
|
|
added subscriber Gerry Drudy |
| 2017-01-18 01:23:50 |
Kota Tsuyuzaki |
bug |
|
|
added subscriber Kota Tsuyuzaki |
| 2017-03-04 01:36:41 |
Jeremy Stanley |
information type |
Private Security |
Public Security |
|
| 2017-03-20 13:56:24 |
Tristan Cacqueray |
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 to the bug as attachments.
--
Ordinarily, during a keystone-authenticated swift3 request,
* the client talks to a swift proxy-server, sending a request with
an Authorization header that includes a credential identifier and
signature;
* swift3 (in the proxy-server's pipeline) recognizes that this is
a S3 request, normalizes the request information to be the same
format as was used in the signature, and includes it in the WSGI
environment;
* s3_token picks up the normalized request, credential identifier,
and user-provided signature and sends them all to keystone;
* keystone's s3 extension uses the credential identifier to look up
the credential's secret, signs the normalized request, and
compares the user-provided signature to the expected one. If they
match, a fresh project-scoped token is issued; otherwise a 401 is
returned.
* s3_token either bubbles up the 401 response or puts the token and
tenant information into the WSGI environment so swift3 and
auth_token may continue handling the request.
Given knowledge of the HTTP method, path, and headers of a valid past
request, an attacker can bypass swift and obtain a project-scoped
token directly from keystone. This may be done well after the initial
request (and resulting token) have expired. The new token may be used
to access any service for which the original user is authorized.
Proposed solution:
Have the s3 extension in keystone verify that the request came from
the s3_token middleware. This may be done via either a service token
(similar to what's done in keystonemiddleware's auth_token middleware)
or a rotating pre-shared key (similar to what's done in swift's
tempurl middleware).
Alternative solutions:
Have the s3 extension only enabled in the v2.0 admin pipeline,
remove it from the v3 pipeline, and expose the v2.0 admin endpoint
only on internal networks. With the convergence of the admin and
public pipelines in v3, this seems unlikely to provide a long-term
solution. However, it may be a useful mitigation for deployments
that cannot quickly upgrade.
Have the s3 extension parse the normalized request, find the
timestamp, and reject requests with a timestamp more than 5 minutes
off from the server's time. This conflates keystone's responsibility
(authentication) with that of swift3 (authorization) and leads to
duplicated efforts.
Additional mitigation:
Require users to change their S3/EC2 credentials regularly.
(Note that while this is similar to bug #1561199, the two bugs cover
separate issues. 1561199 involves inter-middleware communication
within a single WSGI pipeline. This bug involves the communication
between separate services.) |
Ordinarily, during a keystone-authenticated swift3 request,
* the client talks to a swift proxy-server, sending a request with
an Authorization header that includes a credential identifier and
signature;
* swift3 (in the proxy-server's pipeline) recognizes that this is
a S3 request, normalizes the request information to be the same
format as was used in the signature, and includes it in the WSGI
environment;
* s3_token picks up the normalized request, credential identifier,
and user-provided signature and sends them all to keystone;
* keystone's s3 extension uses the credential identifier to look up
the credential's secret, signs the normalized request, and
compares the user-provided signature to the expected one. If they
match, a fresh project-scoped token is issued; otherwise a 401 is
returned.
* s3_token either bubbles up the 401 response or puts the token and
tenant information into the WSGI environment so swift3 and
auth_token may continue handling the request.
Given knowledge of the HTTP method, path, and headers of a valid past
request, an attacker can bypass swift and obtain a project-scoped
token directly from keystone. This may be done well after the initial
request (and resulting token) have expired. The new token may be used
to access any service for which the original user is authorized.
Proposed solution:
Have the s3 extension in keystone verify that the request came from
the s3_token middleware. This may be done via either a service token
(similar to what's done in keystonemiddleware's auth_token middleware)
or a rotating pre-shared key (similar to what's done in swift's
tempurl middleware).
Alternative solutions:
Have the s3 extension only enabled in the v2.0 admin pipeline,
remove it from the v3 pipeline, and expose the v2.0 admin endpoint
only on internal networks. With the convergence of the admin and
public pipelines in v3, this seems unlikely to provide a long-term
solution. However, it may be a useful mitigation for deployments
that cannot quickly upgrade.
Have the s3 extension parse the normalized request, find the
timestamp, and reject requests with a timestamp more than 5 minutes
off from the server's time. This conflates keystone's responsibility
(authentication) with that of swift3 (authorization) and leads to
duplicated efforts.
Additional mitigation:
Require users to change their S3/EC2 credentials regularly.
(Note that while this is similar to bug #1561199, the two bugs cover
separate issues. 1561199 involves inter-middleware communication
within a single WSGI pipeline. This bug involves the communication
between separate services.) |
|
| 2018-01-25 08:54:13 |
Colleen Murphy |
keystone: status |
New |
Fix Released |
|
| 2019-01-28 20:55:30 |
Lance Bragstad |
keystone: milestone |
|
queens-3 |
|
| 2021-02-17 19:52:01 |
Jeremy Stanley |
ossa: status |
Incomplete |
Won't Fix |
|
