This paper deals with the understanding of the Vulnerability and the mitigation process.

1. Vulnerability in libxml2
Denial of Service attack prevention
XML is a very popular markup language, first standardized in the late 1990's and adopted by countless
software projects. It is used in configuration files, document formats (such as OOXML, ODF, PDF, RSS,
...), image formats (SVG, EXIF headers), and networking protocols (WebDAV, CalDAV, XMLRPC, SOAP,
XMPP, SAML, XACML, …). These examples barely scratch the surface. XML is so pervasive that any
weakness or security vulnerability that affects XML generally, no matter how minor, can have a serious
impact on the world's computer systems overall due to the variety and unpredictability of contexts it is
used in. Certain features built into the design of XML, namely inline schemas and document type
definitions (DTDs) are a well-known source of potential security problems. Despite being publicly
discussed for more than a decade, a significant percentage of software using XML remains vulnerable to
malicious DTDs. As one would expect with any well-known, but commonly found type of vulnerability,
this situation stems from the fact that overall awareness within the development community remains
low, while the behavior of many XML parsers is to expose risky features by default. This paper is an
attempt to approach these problems by providing an up-to-date reference of a wide variety of XML
schema and DTD attacks. Meanwhile, we hope any additional awareness this brings will help to
encourage developers of XML library vendors to disable the most dangerous of features by default and
improve API documentation to mitigate any remaining risks.
On 16 October 2014, a vulnerability was reported in libxml2, a library for the processing of eXtensible
Markup Language (XML). XML is a language for the exchange of structured information between
applications. Attackers can use this vulnerability to disrupt the availability of (web) applications through
a so called Denial-of-Service (DoS) attack. The vulnerability is caused due to an error in the processing of
XML files and can be exploited to exhaust all available memory via a specially crafted XML file containing
a predefined entity inside an entity definition.
The vulnerability is reported in versions 2.7.0 and 2.7.1.
Effect of this vulnerability
Successful attacks can cause an application to consume the full CPU power of a system such that other
applications are not able to access the CPU, and thus, cannot function properly. This could mean that a
web application is no longer available to end users.
Every XML based interface that is available over the internet and that makes use of libxml2 can be
remotely exploited. This is not the case if filtering is implemented or if the application sufficiently filters
user input. Examples of this type of interface are SOAP connections, XML-RPC and REST interfaces.
Exploitation of this vulnerability leads to libxml2 consuming all available CPU power. Because
Processor capacity is subsequently no longer available to other applications, the system or applications
on this system will be no longer available. Practically, this could mean that a web application is no longer

2. available to end users. In this case, the application must be restarted in order for the service to become
available again. In some cases, exploitation leads not to CPU overload, but also to exhaustion of memory
and disk resources. This is largely application specific.
Déjà vu
The vulnerability (also known as CVE-2014-3660) can be exploited on several platforms that depend on
libxml2 and resembles a variation of the well-known "Billion Laughs” vulnerability that was discovered
in 2003.
The most well-known XXE-related denial of service attack is the "billion laughs" attack which exploits the
ability to define nested entities defined within an XML DTD to build an XML memory bomb. This bomb is
a specially-crafted document that an attacker writes with nested entities and in-line DTDs that will cause
the parser to generate an exponentially expanded payload, potentially overloading the application
process memory and causing a disruption in service. For example:
<?xml version="1.0"?>
<!DOCTYPE lolz [
<!ENTITY lol "lol">
<!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
<!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
<!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
<!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
<!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
<!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>
Going through the evaluation process depicted in the example above, when an XML parser loads this
document it will include one root element “lolz” that contains the defined entity “&lol9;”. The “&lol9;”
entity expands to a string containing ten “&lol8;” entities. Each “&lol8;” entity is expanded to ten other
“&lol7;” entities and so forth, until it reaches the leaf entity “&lol;”. After processing all of the
expansions, the entities are resolved through string substitutions and consequently would incur
considerable amounts of memory resources – in such attacks a ( < 1 KB) block of XML can consume
almost 3GB of memory.

3. Mitigation
It is highly recommended a system upgrade to a libxml2 version that is not vulnerable. If libxml2 is
supplied in combination with a device or other software, the supplier should be asked for a version
which supports a non-vulnerable version of libxml2. If upgrading is not an option, then it is also
recomended evaluating the risk of this vulnerability for your organization and, according to the results,
implementing the solutions considered necessary:
1. Limit the possibilities for a user to import XML content. Especially, make sure the user has no control
over the DOCTYPE in an XML file.
2. Validate XML contents before offering them to libxml2. This validation can be an XML firewall that
scans the XML file or a separate XML parser that is not based on libxml2 (e.g. libexpat) and parses the
XML before libxml2 parses the file. Also, make sure that the validation is performed on raw content and
not on already processed content, as in the latter case, the XML will already be directed to libxml2.
3. Shield XML parsers wherever possible. If the XML parser does not need to be publicly available, then
make sure that access is restricted by a firewall or by some sort of authentication mechanism.
The use of an alternate XML parser is not seen as a practical solution, because this will require a partial
rewrite of the application. This may be technically complex.
Vulnerable version: 2.7.0 and 2.7.1.
Solution:
1. Update to version 2.7.2.
ftp://xmlsoft.org/libxml2/
2. Follow the mitigation steps
Attribution: National Cyber Security Centre