Oxide introduced the ability to set an expiration for API tokens starting in release 15. Additionally, silo administrators can set the maximum expiration of every access token, with the goal that renewing tokens past their expiration would require re-authenticating with the identity provider to generate new tokens.
We have recently discovered that an API token can be used to generate new tokens that expire past the expiration of the original token used to create them:
An attacker who already compromised a token through other means can extend their access to the Oxide API past the token expiration, using new tokens generated by that original token.
An authorized user can bypass a silo’s maximum token expiration time, potentially unknowingly.
This is fixed in release 17.1, which will limit the maximum expiration of an API token to the expiration of the token that created it. Tokens created or approved using a browser console session are not affected by this.
| Revision | Date (YYYYMMDD) | Changes |
|---|---|---|
1.1 | 20251118 | Update docs site links |
1.0 | 20251117 | Initial Release |
Impact
This vulnerability can be exploited by an attacker who has already obtained a valid Oxide API token (and thus already has access to the Oxide API) to extend their window of access past that token’s expiration, potentially indefinitely. It does not allow an attacker to gain more privileges than they already have.
This vulnerability could also allow silo users to extend their legitimate API tokens past the maximum expiration date configured by silo administrators, potentially unknowingly.
Action Required
Update the Oxide software to version 17.1 (must be scheduled with Oxide Support).
Mitigations
There is no current mitigation for the affected releases.
While audit logs were introduced in release 16, they do not currently contain the ID of the API token used to send the request. Audit logs only record all token creation requests by filtering for the device_auth_confirm operation ID. We are planning to add token IDs to audit logs in release 18 (see omicron#8813).
After upgrading to release 17.1, we recommend silo admins review all
existing tokens, using the Oxide API
(/v1/users/{user_id}/access-tokens).
Technical Background
The Oxide rack uses the OAuth device flow to issue device tokens (commonly referred as API tokens). As of today, it is the only way to get a token for the Oxide API. With the device flow, the user approves the issuance of the token using an existing authenticated session. Once the issuance is approved, the client can request the new token from the Oxide API.
When using the Oxide console to approve the issuance (as it’s done in most cases, including with the Oxide CLI), this presents no security concerns: console sessions are short-lived, they require at least daily re-authentication with the identity provider, and it’s expected that authenticating with the console allows generating tokens expiring beyond the console session.
Issuance can also be approved with existing API tokens, which can be (for example) useful to create short-lived Oxide API tokens from a longer-lived token. In this case, generating tokens expiring beyond the originating token subverts that expiration. In other words, any existing token could create a new version of itself.