Shibboleth Identity Provider Security Advisory [12 December 2022] OpenSAML-Java Security Advisory [12 December 2022]

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

Shibboleth Identity Provider Security Advisory [12 December 2022]
OpenSAML-Java Security Advisory [12 December 2022]

Older releases of the Shibboleth Identity Provider and OpenSAML-Java
library are potentially vulnerable to attacks ranging from denial of
service to remote code execution when given specially-crafted
encrypted XML to decrypt. Some decryption use cases include
unauthenticated message processing, so are widely accessible.

While the current releases of both software products (V4.2.0+) are
believed to be protected from the worst implications of this issue,
many people operate older releases of both the Identity Provider and
OpenSAML, so we are publishing this advisory in part as a courtesy.

It is believed that the worst outcomes on older versions also depend
on the use of non-current releases of the Java JDK, even as recent
as those prior to August of 2022.

At this time, it is believed that the risk of similar attacks in the
Shibboleth SP are not significant. We will update this, and publish a
second advisory in the event this determination changes.

OpenSAML and IdP mis-handle malicious encrypted XML content
======================================================================
The XML Encryption specification, much as the original XML Signature
specification, contains an over-abundance of generality in various
areas, including the potential use of XSLT and XPath "transforms"
as processing instructions while calculating the encrypted content
to decrypt.

SAML provides very specific guidelines for how signed XML needs to
look, allowing pre-validation to prevent many problems. It provides
much less guidance on this matter for encrypted XML.

The OpenSAML Java library, up to and including V4.2.0, does not
perform sufficient validation on the content to outright prevent
execution of some malicious transforms. (OpenSAML V4.2.0 is present
in the V4.2.x releases of the Shibboleth Identity Provider.)
However, the Santuario XML Signature/Encryption library release (2.3.0)
used by these versions of our software contains a default-on secure
processing mode that precludes the worst of these attacks out of the
box, and so we know of no immediately practical attacks against these
versions of our software.

Unfortunately, older versions of our software rely on older Santuario
versions that do not default to this secure processing mode. They are
therefore potentially vulnerable, and these attacks are able to exploit
critical security vulnerabilities in versions of Java whose XSLT
implementation has not been patched.

There have been at least two remote code execution vulnerabilities
reported against Xalan-J, and in turn against Java, in the past 8 years,
one as recent as this past summer. As a result. versions of Java with
patch levels older than August 2022 are believed to be vulnerable to
at least one such issue.

Note that the actual Java LTS release (Java 8, Java 11, Java 17) is
not the relevant issue, but the underlying patch level of a given Java
version. All of the sources of OpenJDK provide routine patch updates
on a quarterly basis and these updates are critical. It is also crucial
to use these LTS releases rather than "feature releases" such as
Java 12-16, etc. due to the risk of missing out on such fixes.

Recommendations
===============
Review the versions of Java and the Identity Provider and OpenSAML
software in your deployment. Make sure that Java is fully patched
and current for whichever LTS release you are using, and take steps
to ensure this remains true.

Note that the Shibboleth Project does not distribute Java in any of
our packaging, most particularly on Windows, where there is no
built-in source of Java and maintaining currency requires additional
effort. Some third-party packaging sources do include Java and you
should ensure you are staying up to date via those sources.

This Red Hat bug report [1] on one of the vulnerabilities mentions
the specific patch levels released this summer that address the
latest issue. Those Oracle patch levels refer to Java "in general"
and may not apply in specific instances where vendors have distributed
Java themselves (e.g., Debian and so on). When in doubt, always use
"the latest" Java for your LTS version and platform.

Obviously you should be taking steps to upgrade to a current IdP
version, but the advice above is critical if you cannot do so quickly.

While we do believe the older versions of our software are likely safe
from the worst of the vulnerabilities provided Java is current, we do
not believe that the risk of future attacks is insignificant, and so
this is not a recommended long term answer.

In the event that upgrading promptly is impossible (which would imply
you should be considering alternatives), you MAY want to test a
workaround of replacing the xmlsec-XXX.jar in dist/webapp/WEB-INF/lib
with xmlsec-2.3.0.jar [2] and then rebuild the IdP warfile to deploy
the updated version.

While we believe this is a compatible change for all V4.x IdP
releases, we have not yet tested this workaround, but will update
this advisory if and when we have. We do not know whether this is
likely to help on releases prior to V4.0.0 and have no plans to
investigate this.

We will include an enhancement in all future releases of OpenSAML
to harden the library against this class of attacks to the greatest
extent possible.

Credits
=======
Khoadha of Viettel Cyber Security

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2108554
[2] https://repo1.maven.org/maven2/org/apache/santuario/xmlsec/2.3.0/

URL for this Security Advisory:
https://shibboleth.net/community/advisories/secadv_20221216.txt
----BEGIN PGP SIGNATURE----

iQIzBAEBCgAdFiEE3KoVAHvtneaQzZUjN4uEVAIneWIFAmOcdOAACgkQN4uEVAIn
eWIswxAAx3Y+XnffdX09uewIFxNQSr/MVeN+RjOCYGW4lwgaH5874ecIDTHWEQFz
V4r/LE0pRgYQAILqSobPTRGEPUAwOPxX+7Tn7jPrTgWjcm/Xo3RzXx0m0NWXCjoq
/SIefIQ0O4EmF/KQ6y8EjixPcUn5dAf4YI+TutkBBlxozVXa9+GJS+4jvsi5Dgi1
w+Dpbbw+WTI8iyAULPCa3tnuhPJ1PJJS9m09T2YRsVUxZKQ9E1ZL/OeaoREvPtrO
TYzJSZs2B6bgSw10kHlXcKSH7vPZbokChGng7KPlLkkPP38p3yg3LdQLo5T1Fr6w
7Uwh43lVWlRMWXrQqyGY9o/cZjljVbR7nli+gjEOh8kpMXgyqHkVbb7IKLtes3vf
tBlRS0Efo0oLj2Y5QyxfDT0Qr1U/Mh5BC6/YN4l/zr3pYTvNBOFgAWtgCyJkwbj3
ruSA3hJxjiAHRMekUi1whMIVIM1xg1BRsTZxO9+UZ5SXXKM8rnGFNCM9pl447+tA
k8bVshY19o9laHvPqPL8EjMNSaxl0GGR+kmmobABFnNc/XcCt/kJ3uL744wKzi7y
XlfRivbz60IyPfiwsiN4Xv3iNWIRl7q+0XgRvSGr/buROChU7Kx/FjdnqChxB71B
QgXGvdVN5UEy712EF5Jjsj0lNhblyomgHAjg1cZub53GO/75zfA=
=ugFq
-----END PGP SIGNATURE-----