None of the issues is new. They have been known for a long time. Billion laughs was first reported in 2003. Nevertheless some XML libraries and applications are still vulnerable and even heavy users of XML are surprised by these features. It’s hard to say whom to blame for the situation. It’s too short sighted to shift all blame on XML parsers and XML libraries for using insecure default settings. After all they properly implement XML specifications. Application developers must not rely that a library is always configured for security and potential harmful data by default.
The Billion Laughs attack – also known as exponential entity expansion – uses multiple levels of nested entities. The original example uses 9 levels of 10 expansions in each level to expand the string lol to a string of 3 * 10 9 bytes, hence the name “billion laughs”. The resulting string occupies 3 GB (2.79 GiB) of memory; intermediate strings require additional memory. Because most parsers don’t cache the intermediate step for every expansion it is repeated over and over again. It increases the CPU load even more.
A quadratic blowup attack is similar to a Billion Laughs attack; it abuses entity expansion, too. Instead of nested entities it repeats one large entity with a couple of thousand chars over and over again. The attack isn’t as efficient as the exponential case but it avoids triggering countermeasures of parsers against heavily nested entities. Some parsers limit the depth and breadth of a single entity but not the total amount of expanded text throughout an entire XML document.
An attacker can exhaust additional resources on the machine, e.g. with requests to a service that doesn’t respond or responds with very large files.
An attacker may gain knowledge, when, how often and from which IP address an XML document is accessed.
External entities with references to local files are a sub-case of external entity expansion. It’s listed as an extra attack because it deserves extra attention. Some XML libraries such as lxml disable network access by default but still allow entity expansion with local file access by default. Local files are either referenced with a file:// URL or by a file path (either relative or absolute).
This case is similar to external entity expansion, too. Some XML libraries like Python’s xml.dom.pulldom retrieve document type definitions from remote or local locations. Several attack scenarios from the external entity case apply to this issue as well.
Lxml is protected against billion laughs attacks and doesn’t do network lookups by default.
libxml2 and lxml are not directly vulnerable to gzip decompression bombs but they don’t protect you against them either.
xml.etree doesn’t expand entities and raises a ParserError when an entity occurs.
minidom doesn’t expand entities and simply returns the unexpanded entity verbatim.
genshi.input of genshi 0.6 doesn’t support entity expansion and raises a ParserError when an entity occurs.
The defusedxml package (defusedxml on PyPI) contains several Python-only workarounds and fixes for denial of service and other vulnerabilities in Python’s XML libraries. In order to benefit from the protection you just have to import and use the listed functions / classes from the right defusedxml module instead of the original module. Merely defusedxml.xmlrpc is implemented as monkey patch.
Additionally the package has an untested function to monkey patch all stdlib modules with defusedxml.defuse_stdlib().
All functions and parser classes accept three additional keyword arguments. They return either the same objects as the original functions or compatible subclasses.
disallow XML with a <!DOCTYPE> processing instruction and raise a DTDForbidden exception when a DTD processing instruction is found.
disallow XML with <!ENTITY> declarations inside the DTD and raise an EntitiesForbidden exception when an entity is declared.
disallow any access to remote or local resources in external entities or DTD and raising an ExternalReferenceForbidden exception when a DTD or entity references an external resource.
The fix is implemented as monkey patch for the stdlib’s xmlrpc package (3.x) or xmlrpclib module (2.x). The function monkey_patch() enables the fixes, unmonkey_patch() removes the patch and puts the code in its former state.
The monkey patch protects against XML related attacks as well as decompression bombs and excessively large requests or responses. The default setting is 30 MB for requests, responses and gzip decompression. You can modify the default by changing the module variable MAX_DATA . A value of -1 disables the limit.
DEPRECATED The module is deprecated and will be removed in a future release.
The module acts as an example how you could protect code that uses lxml.etree. It implements a custom Element class that filters out Entity instances, a custom parser factory and a thread local storage for parser instances. It also has a check_docinfo() function which inspects a tree for internal or external DTDs and entity declarations. In order to check for entities lxml > 3.0 is required.
The defusedexpat package (defusedexpat on PyPI) comes with binary extensions and a modified expat library instead of the standard expat parser. It’s basically a stand-alone version of the patches for Python’s standard library C extensions.
XML, XML parsers and processing libraries have more features and possible issue that could lead to DoS vulnerabilities or security exploits in applications. I have compiled an incomplete list of theoretical issues that need further research and more attention. The list is deliberately pessimistic and a bit paranoid, too. It contains things that might go wrong under daffy circumstances.
XML parsers may use an algorithm with quadratic runtime O(n 2) to handle attributes and namespaces. If it uses hash tables (dictionaries) to store attributes and namespaces the implementation may be vulnerable to hash collision attacks, thus reducing the performance to O(n 2) again. In either case an attacker is able to forge a denial of service attack with an XML document that contains thousands upon thousands of attributes in a single node.
I haven’t researched yet if expat, pyexpat or libxml2 are vulnerable.
None of Python’s standard XML libraries decompress streams except for xmlrpclib. The module is vulnerable <https://bugs.python.org/issue16043> to decompression bombs.
lxml can load and process compressed data through libxml2 transparently. libxml2 can handle even very large blobs of compressed data efficiently without using too much memory. But it doesn’t protect applications from decompression bombs. A carefully written SAX or iterparse-like approach can be safe.
may impose more threats for XML processing. It depends if and how a processor handles processing instructions. The issue of URL retrieval with network or local file access apply to processing instructions, too.
DTD has more features like <!NOTATION>. I haven’t researched how these features may be a security threat.
XPath statements may introduce DoS vulnerabilities. Code should never execute queries from untrusted sources. An attacker may also be able to create an XML document that makes certain XPath queries costly or resource hungry.
XPath injeciton attacks pretty much work like SQL injection attacks. Arguments to XPath queries must be quoted and validated properly, especially when they are taken from the user. The page Avoid the dangers of XPath injection list some ramifications of XPath injections.
This feature should be disabled when XML files from an untrusted source are processed. Some Python XML libraries and libxml2 support XInclude but don’t have an option to sandbox inclusion and limit it to allowed directories.
A validating XML parser may download schema files from the information in a xsi:schemaLocation attribute.
You should keep in mind that XSLT is a Turing complete language. Never process XSLT code from unknown or untrusted source! XSLT processors may allow you to interact with external resources in ways you can’t even imagine. Some processors even support extensions that allow read/write access to file system, access to JRE objects or scripting with Jython.
Several other programming languages and frameworks are vulnerable as well. A couple of them are affected by the fact that libxml2 up to 2.9.0 has no protection against quadratic blowup attacks. Most of them have potential dangerous default settings for entity expansion and external entities, too.
Perl’s XML::Simple is vulnerable to quadratic entity expansion and external entity expansion (both local and remote).
libxml-ruby and hpricot don’t expand entities in their default configuration.
PHP’s SimpleXML API is vulnerable to quadratic entity expansion and loads entities from local and remote resources. The option LIBXML_NONET disables network access but still allows local file access. LIBXML_NOENT seems to have no effect on entity expansion in PHP 5.4.6.
Untested. The documentation of Xerces and its Xerces SecurityMananger sounds like Xerces is also vulnerable to billion laugh attacks with its default settings. It also does entity resolving when an org.xml.sax.EntityResolver is configured. I’m not yet sure about the default setting here.
See https://www.python.org/psf/license for licensing details.
Many thanks to my employer semantics for letting me work on the issue during working hours as part of semantics’s open source initiative.
No longer pass html argument to XMLParse. It has been deprecated and ignored for a long time. The DefusedXMLParser still takes a html argument. A deprecation warning is issued when the argument is False and a TypeError when it’s True.
defusedxml now fails early when pyexpat stdlib module is not available or broken.
defusedxml.ElementTree.__all__ now lists ParseError as public attribute.
The defusedxml.ElementTree and defusedxml.cElementTree modules had a typo and used XMLParse instead of XMLParser as an alias for DefusedXMLParser. Both the old and fixed name are now available.
Add more demo exploits, e.g. python_external.py and Xalan XSLT demos.
As per http://seclists.org/oss-sec/2013/q1/340 please REJECT CVE-2013-0278, CVE-2013-0279 and CVE-2013-0280 and use CVE-2013-1664, CVE-2013-1665 for OpenStack/etc.
Add demo exploit for external entity attack on Python’s SAX parser, XML-RPC and WebDAV.