Hej, Här kommer den security advisory för Shibboleth IdP som vi informerade om tidigare i veckan. Det är nog bra om ni tog i detta innan jul. Pål > -----Original Message----- > From: announce &lt;announce-bounces(a)shibboleth.net&gt; On Behalf Of Cantor, > Scott via announce > Sent: Friday, December 16, 2022 2:44 PM > To: announce(a)shibboleth.net > Cc: Cantor, Scott &lt;cantor.2(a)osu.edu&gt; > Subject: Shibboleth Identity Provider + OpenSAML Security Advisory [16 > December 2022] > > Signed advisory follows. > > Upshot: > This is for the IdP and also anyone using OpenSAML directly. > Patch Java, patch Java, patch Java. > The 4.2.x releases are basically safe because of xmlsec-2.3.0.jar > Backporting > xmlsec-2.3.0.jar in place of xmlsec-<earlier> probably works for any 4.x > install but we haven't officially verified that. > > -- Scott > >  -----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 > > > -- > To unsubscribe from this list send an email to announce- > unsubscribe(a)shibboleth.net