Bug 2105317

Summary: Application credential token is valid beyond credentials expiration
Product: Red Hat OpenStack Reporter: Pierre Prinetti <pprinett>
Component: openstack-keystoneAssignee: Douglas Mendizábal <dmendiza>
Status: CLOSED DUPLICATE QA Contact: Jeremy Agee <jagee>
Severity: high Docs Contact:
Priority: medium    
Version: 16.2 (Train)CC: alee, dwilde, jschluet, maandre, mbooth, ntait, oblaut, security-response-team
Target Milestone: zstreamKeywords: Security, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-05-31 19:08:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Pierre Prinetti 2022-07-08 14:15:18 UTC
Description of problem:
Keystone issues tokens with the default lifespan regardless of the lifespan of the application credentials used to issue them.
If the configured lifespan of an identity token is set to be 1h, and the application credentials expire in 1 minute from now, a newly issued token will outlive the application credentials used to issue it by 59 minutes.

How reproducible: 100%

Steps to Reproduce:
1. Create application credentials with short expiration time (e.g. 10 seconds)
2. openstack token issue
--> the returned token has standard expiration, for example 1 hour. The script below confirms that the token continue being valid after the application credentials expired.

```bash
#!/usr/bin/env bash

set -Eeuo pipefail

openstack image create --disk-format=raw --container-format=bare --file <(echo 'I am a Glance image') testimage -f json > image.json

image_url="$(openstack catalog show glance -f json | jq -r '.endpoints[] | select(.interface=="public").url')$(jq -r '.file' image.json)"

openstack application credential create \
	--expiration="$(date --utc --date '+10 second' +%Y-%m-%dT%H:%M:%S)" \
	token_test \
	-f json \
	> appcreds.json

cat <<EOF > clouds.yaml
clouds:
    ${OS_CLOUD}:
        auth:
            auth_url: <auth_url>
            application_credential_id: '$(jq -r '.id' appcreds.json)'
            application_credential_secret: '$(jq -r '.secret' appcreds.json)'
        auth_type: "v3applicationcredential"
        identity_api_version: 3
        interface: public
        region_name: <region_name>
EOF
# Override ~/.config/openstack/secure.yaml
touch secure.yaml

openstack token issue -f json > token.json

echo "appcreds expiration: $(jq -r '.expires_at' appcreds.json)"
for i in {1..10}; do
	sleep 100
	echo -ne "$(date --utc --rfc-3339=seconds)\t"
	curl -isS -H "X-Auth-Token: $(jq -r '.id' token.json)" --url "$image_url" | head -n1
done

```

Actual results (on a cloud with tokens duration of 24h):
appcreds expiration: 2022-07-08T13:55:02.000000
2022-07-08 13:56:38+00:00       HTTP/1.1 200 OK
2022-07-08 13:58:19+00:00       HTTP/1.1 200 OK
2022-07-08 14:00:00+00:00       HTTP/1.1 200 OK
2022-07-08 14:01:42+00:00       HTTP/1.1 200 OK
2022-07-08 14:03:23+00:00       HTTP/1.1 200 OK
2022-07-08 14:05:07+00:00       HTTP/1.1 200 OK
2022-07-08 14:06:49+00:00       HTTP/1.1 200 OK
2022-07-08 14:08:37+00:00       HTTP/1.1 200 OK
2022-07-08 14:10:18+00:00       HTTP/1.1 200 OK
2022-07-08 14:12:00+00:00       HTTP/1.1 200 OK

Expected results:
appcreds expiration: 2022-07-08T13:55:02.000000
2022-07-08 13:54:38+00:00       HTTP/1.1 200 OK
2022-07-08 13:58:19+00:00       HTTP/1.1 401 Unauthorized
2022-07-08 14:00:00+00:00       HTTP/1.1 401 Unauthorized
2022-07-08 14:01:42+00:00       HTTP/1.1 401 Unauthorized
2022-07-08 14:03:23+00:00       HTTP/1.1 401 Unauthorized
2022-07-08 14:05:07+00:00       HTTP/1.1 401 Unauthorized
2022-07-08 14:06:49+00:00       HTTP/1.1 401 Unauthorized
2022-07-08 14:08:37+00:00       HTTP/1.1 401 Unauthorized
2022-07-08 14:10:18+00:00       HTTP/1.1 401 Unauthorized
2022-07-08 14:12:00+00:00       HTTP/1.1 401 Unauthorized

Comment 3 Nick Tait 2022-09-13 21:15:32 UTC
Please use CVE-2022-2447 to track this vulnerability. Severity has been rated such that there is no need for an embargo, I am opening this bug up to the public.

Comment 4 Jon Schlueter 2023-05-31 19:08:20 UTC

*** This bug has been marked as a duplicate of bug 2117923 ***

Comment 5 Jon Schlueter 2023-05-31 19:11:11 UTC
This has a CVE and release tracker for 16.2 that should be used instead of this one.