-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Shibboleth Identity Provider Security Advisory [3 November 2014] Updated 6 November 2014 to clarify unendorsement requirement. Xerces-J XML Parser Vulnerable to Denial of Service ========================================================================= The Shibboleth IdP software has historically required the use of the Xerces-J XML parser and was shipped with packaging, configuration, and documentation that required the use of the Java Endorsement mechanism to override the JDK-supplied parser and substitute the use of Xerces. In 2013, a denial of service issue was disclosed in the parser, but overlooked by most of the industry until recently. The Xerces Project corrected the bug in their source tree, but has never issued an update that addresses the problem. The Xerces issue was assigned CVE-2013-4002. Recent versions of the Shibboleth software can be configured to use the standard XML parser provided with the Oracle or OpenJDK Java software that are supported for use. An updated version of the IdP, V2.4.3, is also now available that explicitly omits the Xerces library and related files, and includes a configuration change required for the use of the built-in parser. Versions of the IdP prior to V2.4.0, which are formally unsupported, contain dependencies that make it more difficult to change the parser used. In such cases, and in fact with newer versions, we recommend an additional change that also closes the vulnerability, limiting the size of form POST data allowed by the Java container software (e.g., Tomcat). The recommended container for all versions of Shibboleth is now Jetty 9, which defaults to a POST limit of 200k and is not vulnerable to this issue. Tomcat, along with most other containers, defaults to a larger limit that should be changed to mitigate this issue and make future threats much less likely. Affected Versions ================= All versions of the Identity Provider using the Xerces-J parser, typically through the Java Endorsement mechanism. All versions prior to V2.4.3 include the Xerces software, and include configuration settings that work with it specifically. That is, if the conf/internal.xml file is unmodified, you are using Xerces and are vulnerable to this issue. Recommendations =============== All containers other than Jetty: refer to your container documentation and if possible, configure the container to reject form POST sizes larger than 100k. In the case of Tomcat (including many versions of JBoss), the maxPostSize attribute is used to adjust this limit in any element in conf/server.xml (this setting can apply to both HTTP/HTTPS and AJP). Setting maxPostSize="100000" is a reasonable limit. Deployers running IdP V2.4.0 or greater should unendorse all of the Xerces/Xalan and supporting XML libraries from your container. All of the libraries included in the original $IDP_HOME/lib/endorsed location need to be removed, and you should remove that directory. You will have to determine exactly how and where you endorsed this libraries in your particular container. You MUST also adjust your configuration as follows: Edit $IDP_HOME/conf/internal.xml. Find the bean definition containing class="org.apache.xerces.util.SecurityManager" and change the class name to "com.sun.org.apache.xerces.internal.util.SecurityManager" If your IdP startup fails with a ClassNotFound error mentioning "org.apache.xerces.util.SecurityManager", this is due to failure to edit the file as described (or it may mean you're using an unsupported Java implementation that does not include the Oracle/Sun JAXP parser). IdP V2.4.3 is also available and no longer includes the unneeded jars, does not install a lib/endorsed directory, and includes an internal.xml file modified as above. Upgrading to this version will not overwrite the installed copy of internal.xml, but you can compare your version to the default file found in src/installer/resources/conf-tmpl/internal.xml NOTE: if you choose to use an unsupported JDK version from a different source, you may need to experiment or do some research to determine the appropriate parser configuration settings to use in internal.xml. Note also that it is possible to introduce vulnerabilities if improper settings are applied. Credits ======= Kaspar Brand, SWITCH URL for this Security Advisory http://shibboleth.net/community/advisories/secadv_20141103.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCgAGBQJUW5VCAAoJEDeLhFQCJ3li2+QQAL6zY+FKnBNZWVrZMvne6oWL ruMft10tfD2FdCtNsfhd0UhoLKCLyPvaY1Rcqn3Lh5O7XMdI4gFhy0XWGDB0eH2T R9RDoy7PrUMESK3OeA3NHpQ8b3dpcGh9tJtP7Vv+PtX+Ux6EhVQJu8UIC3P5m0y5 Q0P7qkAVTIfquVi/ZNsw5EvI9vghqfINVVyj8GEp6OPyWXzffBiuPZmOtfsvavFf jy0y+J0UJoluQndzm0+33dSyQBmr8KhwuSqfrsqrgKwtQ3KWNviSzAvUBqMKDHVU MSkeGCbbZlE91IoBeFt9DM2FKj4wkFUaWcj7ndScyYVN7tUDrikjdvLC7QzCxYTT Y1sMFA+1YPkSBERNmn3G62yNVDHehDeBpGhKMZvN305kVQhaDkmmS9u9oPcJxm+Z 6zLq8QPCP6OG73XAwTq4hxhdAIYB8UdAGPQp9rWYzRYol4yw2TNBrBsScW0igrQS JEnzwKbsuH/ql+972yCmHMAELxyztPpSuT0J84fDTNH6SIdqFh5GWwyxcfPgMP6c zbFQjBFagdODWzEHGlO67uamlKNZdH1cshF0mD+9/22zu3Mot9dmM5D9l9Y5t6VH MW3CoSaa1qcAl7KDDDbOZCZP66WbWNXGFTE85KG0MtQXecdcNyo5bT3G5soDQaSS vXIHzWy8Zs5N5NGf+X2L =WG5w -----END PGP SIGNATURE-----