-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3KoVAHvtneaQzZUjN4uEVAIneWIFAmflWogACgkQN4uEVAIn
eWJGrA/7BrrH9zf3ttoGDYi9IYr5m0SiVYIrYwERO/vha7bJULwab8VakOdYYC6/
XLJgJKihcPH23trIgpkCyIqtnUmjkjIaYbvE7I8h19P7uJxa7RZe8+LtWLfIFT/O
laqBrtx488XV6HrqBwsuUhaLYh0CXlL+V89w0YIs3QX/o+GGEPb3zKAwgWKPB6zD
Ra6AQ24hJQD6RAnD0aLT1+ST7AnWE08rZpx+UATVUodMDwp+du8hIPtDt5GtHdPQ
WKmBX84TxOd/iR+ayNYndA5VUPXKbcpUhuCtlMVK2OvIh1hmc/RTzwL4WQmjxgmQ
iEFHp8Emj5Cv/wm5mUO8aTUc3Y4z7+pUVMahNELW1CJxkMFtBBWTooS9/H/IBGv7
8OxiB3GMYH/DnmXLhmZQxwz3bRX1BotLYc0SxcB5aLb0pnm7ulERxwQvhBWaOj7F
jkqguQTtwcDzpK9ELNrtDMeY65OqklpecEXk4hvGufIIAv8Q4noNHKQlBcQbPXhi
/ddLAj0MIvC0CL9ACgXNY7ien1SKvIOUzXS1q3jMgAzoQplPrt7LgxL1TcCO1HG2
sSm0DB37EJczsoFnE7vSaGXv2M4oWEH1cco92+Z6Ij7cXI9KVYA2HT6vvquSaVgx
KVOizPo5eUCj1XSHBrb7swyu03gbD6xtBOGeHb9K5kE+TArI1Wc=
=AfBz
-----END PGP SIGNATURE-----