OpenSAML-J Security Advisory [ 13 December 2013 ] OpenSAML Java ParserPool and Decrypter Vulnerable To XML Attacks ===================================================================== OpenSAML Java ships with a couple of implementations of the ParserPool interface (org.opensaml.xml.parse.BasicParserPool and org.opensaml.xml.parse.StaticBasicParserPool). Due to pool configuration parameters set by the default constructor, both implementations are vulnerable to a variety of XML attacks, both denial-of-service and information disclosure. The latter are often referred to as XML External Entity (XXE) attacks. Both categories of attacks leverage the use of the XML DOCTYPE declaration. Note that use of DOCTYPE is neither typical nor needed in SAML processing cases. Additionally, the XML and SAML Decrypter implementations (org.opensaml.xml.encryption.Decrypter and org.opensaml.saml2.encryption.Decrypter respectively) use an internally constructed ParserPool instance which is vulnerable to the same types of attacks. Note that the Shibboleth IdP, which makes use of OpenSAML Java, is not vulnerable to these attacks in any supported version, because: 1) the ParserPool instance used is configured per the recommendations below 2) the IdP does not support decryption and does not use the OpenSAML Decrypter. Affected Versions ================= Versions of OpenSAML Java < 2.6.1 Recommendations =============== If you are using either OpenSAML Decrypter implementation, in version 2.6.0 and earlier: There is no mechanism for injecting or configuring the ParserPool used. In this case, it is recommended that you upgrade to OpenSAML version 2.6.1 or higher as soon as possible. If you are not using the OpenSAML Decrypter: It is always recommended that ParserPool instances be configured appropriately, being mindful of application and security requirements. When using a ParserPool for SAML or other XML processing use cases where DOCTYPE and external entities are not used, the following miminum ParserPool configuration is recommended: 1) set pool property 'expandEntityReferences' to 'false' 2) set feature 'javax.xml.XMLConstants.FEATURE_SECURE_PROCESSING' to true 3) set feature 'http://apache.org/xml/features/disallow-doctype-decl' to true #1 and #2 should be supported by all JAXP implementations. #3 is a Xerces-specific feature, including derivatives such as the internal JAXP implementations supplied with the Oracle and OpenJDK JREs. For other JAXP implementations, consult the documentation for the implementation for guidance on how to achieve a similar configuration. Configuring the ParserPool instance per the above is sufficient to mitigate these kinds of XML attacks in OpenSAML Java 2.6.0 and earlier. Also, take special note that MessageDecoder implementations which are subclasses of org.opensaml.ws.message.decoder.BaseMessageDecoder will by default use an insecure internal ParserPool. It is recommended that an appropriately configured ParserPool instance always be supplied at construction time for such MessageDecoder instances. In order to make the OpenSAML ParserPool implementations immune to these types of attack by default, the default parameters at construction time have been updated per the above for OpenSAML versions 2.6.1 and higher. Note that if you are supplying your own feature map to the ParserPool, this map overrides the default feature map and you will need to explicitly include the above features in your supplied feature map. Credits ======= David Illsley (affiliation unknown) Ron Gutierrez, Gotham Digital Science David Jorm, Red Hat Security Response Team URL for this Security Advisory http://shibboleth.net/community/advisories/secadv_20131213.txt This advisory has been assigned CVE-2013-6440 by the National Vulnerability Database. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-6440