[Saml-admins] Fwd: Shibboleth Identity Provider Security Advisory [26 March 2025]

Begin forwarded message: From: "Cantor, Scott via announce" <announce(a)shibboleth.net> Subject: Shibboleth Identity Provider Security Advisory [26 March 2025] Date: 27 March 2025 at 15:04:56 CET To: "announce(a)shibboleth.net" <announce(a)shibboleth.net> Cc: "Cantor, Scott" <cantor.2(a)osu.edu> Reply-To: users(a)shibboleth.net Shibboleth Identity Provider Security Advisory [26 March 2025] An updated version of the OpenSAML Java library is available which corrects a parameter manipulation vulnerability when using SAML bindings that rely on non-XML signatures. The Shibboleth Identity Provider is impacted by this issue, and it manifests as a low to moderate security issue in that context, depending on its configuration. A separate advisory may be issued discussing the broader implications for those using the OpenSAML library directly. Parameter manipulation allows the forging of signed SAML messages ================================================================= Vulnerabilities in the OpenSAML library used by the Shibboleth Identity Provider allowed for creative manipulation of parameters combined with reuse of the contents of older requests to fool the library's signature verification of non-XML based signed messages. The uses of that feature involve very low or low impact use cases without significant security implications, and allow an attacker to forge signed messages used to request authentication or logout, neither of which presents a major concern. The IdP's support for inbound SAML assertions (proxying SAML authentication) did partially support the POST-SimpleSign binding but is not believed vulnerable to an attack. This support was not documented and has been removed in this patch out of caution. A moderate issue resulting in potential information disclosure (but not forged logins) exists when the "skipEndpointValidationWhenSigned" profile configuration option is used [1]. This option does not implement standardized SAML behavior, and allows an IdP to be manipulated into sending responses to any URL contained in a request, provided the request is signed. This vulnerability allows an attacker to manipulate the IdP into responding to a URL of the attacker's choice, but in doing so the response can only be used compliantly by a Service Provider operating under the expected entityID and at that exact location. Furthermore, in most cases the enclosed data would be encrypted under a key known only to the legitimate SP. It would be an unusual and deliberate decision to implement this feature with an SP *not* also having an encryption key to use, and moreover to do so while relying on the known-vulnerable AES-CBC encryption algorithm. Thus, a combination of a number of deliberate, and to some extent poor, configuration choices create an information disclosure concern. Recommendations =============== Update to V5.1.4 (or later) of the Identity Provider software. In the meantime, avoiding use of the "skipEndpointValidationWhenSigned" profile option in conjunction with an SP without an encryption key or which does not support the modern AES-GCM data encryption algorithm is advisable as a mitigation. Credits ======= Thanks to Alexander Tan of SecureSAML for discovering and reporting this vulnerability. [1] https://shibboleth.atlassian.net/wiki/x/yKC0vg [2] https://shibboleth.atlassian.net/wiki/x/koO0vg URL for this Security Advisory: https://shibboleth.net/community/advisories/secadv_20250326.txt