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