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

                             CERT-Renater

                   Note d'Information No. 2021/VULN060
_____________________________________________________________________

DATE                : 03/02/2022

HARDWARE PLATFORM(S): /

OPERATING SYSTEM(S): Systems running Shibboleth OIDC OP plugin versions
                                       prior to 3.0.4.

=====================================================================
https://shibboleth.net/community/advisories/secadv_20220131.txt
_____________________________________________________________________


Shibboleth Identity Provider Plugin Security Advisory [31 January 2022]

An updated version of the OpenID Connect OP plugin for the Shibboleth
Identity Provider is now available which corrects a server-side request
forgery vulnerability. This allows attackers to interact with arbitrary
third-party services through the Identity Provider, including the IdP
itself.

This issue is considered of "medium to high" security importance to
deployments, as it is accessible remotely by an unauthenticated attacker,
and raises the risk of further exploit of the IdP in the future.

OpenID Connect OP plugin allows unchecked use of request_uri feature
======================================================================
The OIDC specification allows an RP/client to send its authentication
requests via a request object. These request objects can be either sent
directly via a 'request' parameter or indirectly by passing a URL as the
parameter via 'request_uri'. [1] In the indirect case the OP fetches the
request object via an HTTP-GET request to the specified URL.

The Shibboleth OIDC OP plugin supports this behavior, but does not 
validate the passed 'request_uri' before issuing the HTTP-GET request.
Therefore, an unauthenticated attacker might exploit this to perform 
server-side request forgery and issue malicious HTTP-GET requests
to services reachable by the server running the plugin. In
particular, an attacker could try to access services on the same
server via localhost.

The Shibboleth OIDC OP plugin does not return information from the
issued HTTP response to the attacker when it cannot parse the
response as a JWT.
Therefore, the capabilities of an attacker are mostly limited to
initiating operations on HTTP services. The IdP does not expose any
clearly dangerous operations that might be exploitable in this
fashion, but the risk is unacceptable.

Less critically, an attacker can find out the exact Shibboleth IdP
version by letting the OIDC OP plugin connect to an
attacker-controlled service and inspecting the user agent header in
the HTTP request.


Recommendations
===============
Upgrade to V3.0.4 of the plugin, which requires the `request_uri`
value to be pre-registered in a client's OIDC or SAML metadata.
If you need this feature, be sure to add any allowable URLs to
the metadata. Only exact matching is supported.

Note that the plugin does not support dynamic registration of these
URLs when a client uses the dynamic registration feature. This was a
happy accident but is likely to remain the case for security reasons.

If you do not register any URLs in the metadata, this has the
practical effect of disabling the feature outright.

All previous versions of the OP plugin, including the pre-official releases
(before V3.0), are affected by this vulnerability. For some
deployments, implementing filtering/blocking of requests that
contain the 'request_uri` parameter may be a possible fix until
an upgrade is possible.


Credits
=======
* David Gnedt, SBA Research
* Andreas Bernauer-Puchegger, SBA Research
* Franz Wieshaider, SBA Research

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

This issue has been assigned CVE-2022-24129.

URL for this Security Advisory:
https://shibboleth.net/community/advisories/secadv_20220131.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 +
=========================================================

