Impact

When using client authentication method "privatekeyjwt" [1], OpenId specification says the following about assertion jti:

A unique identifier for the token, which can be used to prevent reuse of the token. These tokens MUST only be used once, unless conditions for reuse were negotiated between the parties

Hydra does not seem to check the uniqueness of this jti value. Here is me sending the same token request twice, hence with the same jti assertion, and getting two access tokens:

$ curl --insecure --location --request POST 'https://localhost//oauth2/token' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'granttype=clientcredentials' \ --data-urlencode 'clientid=c001d00d-5ecc-beef-ca4e-b00b1e54a111' \ --data-urlencode 'scope=application openid' \ --data-urlencode 'clientassertiontype=urn:ietf:params:oauth:client-assertion-type:jwt-bearer' \ --data-urlencode 'clientassertion=eyJhb [...] jTw' {"accesstoken":"zeG0NoqOtlACl8q5J6A-TIsNegQRRUzqLZaYrQtoBZQ.VR6iUcJQYp3uj7pwvL7YtPqGhtyQe5OhnBE2KCp5pM","expiresin":3599,"scope":"application openid","tokentype":"bearer"}⏎ ~$ curl --insecure --location --request POST 'https://localhost//oauth2/token' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'granttype=clientcredentials' \ --data-urlencode 'clientid=c001d00d-5ecc-beef-ca4e-b00b1e54a111' \ --data-urlencode 'scope=application openid' \ --data-urlencode 'clientassertiontype=urn:ietf:params:oauth:client-assertion-type:jwt-bearer' \ --data-urlencode 'clientassertion=eyJhb [...] jTw' {"accesstoken":"wOYtgCLxLXlELORrwZlmeiqqMQ4kRzV-STU2Sollas.mwlQGCZWXN7G2IoegUe1P0Vw5iGoKrkOzOaplhMSjm4","expiresin":3599,"scope":"application openid","tokentype":"bearer"}

Severity

We rate the severity as medium because the following reasons make it hard to replay tokens without the patch:

- TLS protects against MITM which makes it difficult to intercept valid tokens for replay attacks - The expiry time of the JWT gives only a short window of opportunity where it could be replayed

Patches

This will be patched with v1.4.0+oryOS.17

Workarounds

Two workarounds have been identified:

- Do not allow clients to use privatekeyjwt - Use short expiry times for the JWTs

References

https://openid.net/specs/openid-connect-core-10.html#ClientAuthentication

Upstream

This issue will be resolved in the upstream repository https://github.com/ory/fosite

Description

Following Admin APIs in Ory Hydra are vulnerable to SQL injection due to flaws in its pagination implementation:

- listOAuth2Clients - listOAuth2ConsentSessions - listTrustedOAuth2JwtGrantIssuers

Pagination tokens are encrypted using the secret configured in secrets.pagination. If this value is not set, Hydra falls back to using secrets.system. An attacker who knows this secret can craft their own tokens, including malicious tokens that lead to SQL injection.

Preconditions

This issue can be exploited when the following conditions are met:

- One or more admin APIs listed above are directly or indirectly accessible to the attacker - The attacker can pass a raw pagination token to the affected API - The configuration value secrets.pagination is set and known to the attacker, or secrets.pagination is not set and secrets.system is known to the attacker

Impact

An attacker can execute arbitrary SQL queries through forged pagination tokens.

Mitigation

As a first line of defense, immediately configure a custom value for secrets.pagination by generating a cryptographically secure random secret, for example:

openssl rand -base64 32

Next, upgrade Hydra to the fixed version as soon as possible.

Hydra is a Continuous Integration service for Nix based projects. Evaluation of untrusted non-flake nix code could potentially access secrets that are accessible by the hydra user/group. This should not affect the signing keys, that are owned by the hydra-queue-runner and hydra-www users respectively.

ORY Hydra before v1.0.0-rc.3+oryOS.9 has Reflected XSS via the oauth2/fallbacks/error errorhint parameter.

Hydra through 0.1.8 has a NULL pointer dereference and daemon crash when processing POST requests that lack a Content-Length header. read.c, request.c, and util.c contribute to this. The processheaderend() function calls boaatoi(), which ultimately calls atoi() on a NULL pointer.