=====================================================================

                           CERT-Renater

                 Note d'Information No. 2022/VULN008
_____________________________________________________________________

DATE                : 07/01/2022

HARDWARE PLATFORM(S): /

OPERATING SYSTEM(S): Systems running Shibboleth

=====================================================================
https://shibboleth.net/community/advisories/secadv_20220103.txt
_____________________________________________________________________
Shibboleth Identity Provider Plugin Security Advisory [3 January 2022]

An updated version of the OpenID Connect OP plugin for the Shibboleth
Identity Provider is now available which corrects deficiencies in the
support for JWT-based client authentication to the token, introspection,
and revocation endpoints.

This issue is considered of "low" security importance to deployments,
and most deployments likely do not make use of this feature, but it is
enabled by default.

OpenID Connect OP plugin is missing required checks handling JWTs
======================================================================
The OAuth 2 (and OpenID Connect) specifications allow for a variety
of methods for an OAuth client (the relying party) to prove its identity
during API calls to the authorization server's token, introspection,
revocation endpoints.

By far the most common client authentication methods involve client
secrets (essentially just passwords), but the plugin includes support
for the two defined JWT-based methods, defined in section 9 of the
OpenID Connect Core specification [1]. The methods are referred to
as "client_secret_jwt" and "private_key_jwt".

These methods require some checks of the content of the JWT for
"appropriateness", in addition to the verification of the key used
to sign the JWT. Some of these checks are being performed by an
underlying library used by the plugin but a number of others are
missing, including checks for expiration and replay.

As a result, an attacker able to obtain a JWT token by compromising
the protected channel or the client would be able to make use of the
token to forge requests using it as an authenticator. The attacker
would still need to be able to obtain the actual data needed to
make such requests, such as short-lived authorization codes or
refresh tokens. Authorization codes are also checked for replay,
although this depends on having a shared storage model for full
protection.

Note that the signature checking _was_ being performed, so outright
forgery of a JWT itself is not possible via this flaw. In addition,
a separate bug prevented use of these methods from functioning on
any endpoint other than the token endpoint, further limiting exposure.

Recommendations
===============
Update to V3.0.3 or later of the OIDC OP plugin, which is now available.
The IdP's plugin installer can perform this update process.

In doing so, you may need to review and test any use of JWTs to ensure
they conform to the specification now that additional checking is done.

If you are not making use of this feature, consider leveraging the
two supported properties to globally disable use of the JWT methods
(idp.oidc.tokenEndpointAuthMethods,
idp.oidc.dynreg.tokenEndpointAuthMethods).

Credits
=======
This issue was discovered by the Shibboleth Project team itself.

[1]
https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication

URL for this Security Advisory:
https://shibboleth.net/community/advisories/secadv_20220103.txt

=========================================================
+ CERT-RENATER       |    tel : 01-53-94-20-44          +
+ 23/25 Rue Daviel   |    fax : 01-53-94-20-41          +
+ 75013 Paris        |    email:cert@support.renater.fr +
=========================================================