A denial of service flaw was found in the way libxml2, a library providing support to read, modify and write XML and HTML files, performed string substitutions when entity values for external entity references replacement (--noent option) was requested / enabled during the XML file parsing. A remote attacker could provide a specially-crafted XML file containing an external entity expansion, when processed would lead to excessive CPU consumption (denial of service). This a different flaw from CVE-2013-0338. Upstream patch: http://git.gnome.org/browse/libxml2/commit/?id=23f05e0c33987d6605387b300c4be5da2120a7ab
Reference: http://seclists.org/oss-sec/2013/q1/391
Apart from causing DoS, External Entity Expansion could be abused in several other ways, which include: - An attacker can circumvent firewalls and gain access to restricted resources as all the requests are made from an internal and trustworthy IP address, not from the outside. - An attacker can abuse a service to attack, spy on or DoS your servers but also third party services. The attack is disguised with the IP address of the server and the attacker is able to utilize the high bandwidth of a big machine. More details and write-up available at: http://blog.python.org/2013/02/announcing-defusedxml-fixes-for-xml.html This flaw can be mitigated by not expanding external entities, specially the ones which come from untrusted sources. libxml2 already provides mechanisms to disable external entities which applications can use. Closing this flaw as "wontfix"
This issue has been marked as WONTFIX for both Red Hat Enterprise Linux 5 and 6. External Entity Expansion is the default behaviour of libxml2. Applications using libxml2 have an option of turning it off via an API, before parsing an xml file. While external entity expansion is dangerous when parsing untrusted xml files, it is an often required feature of certain applications like docbook, which only parse trusted xml files. For this reason we have decided to keep it on by default and encourage application developers to turn it off, when required.
(In reply to Huzaifa S. Sidhpurwala from comment #7) > External Entity Expansion is the default behaviour of libxml2. Applications > using libxml2 have an option of turning it off via an API, before parsing an > xml file. The above information is not correct. The default behavior of libxml2 is to not expand entity references, whether they are internal or external. Applications using libxml2 can enable entity expansion by setting the XML_PARSE_NOENT parser option. That option enables processing of both internal and external entities. This is not recommended when processing untrusted XML input. Note that the exact scope of this CVE is currently unclear as discussed in further details in the following oss-security mailing list post: http://seclists.org/oss-sec/2014/q2/245 Its description suggests the CVE was created because of lack of easy way for applications to prevent external entity expansion. However, as noted above, the default behavior is to not expand entities. The CVE also references this libxml2 upstream commit: https://git.gnome.org/browse/libxml2/commit/?id=4629ee02ac649c27f9c0cf98ba017c6b5526070f That commit addressed a bug in the way libxml2 handled external entities. Even when entity expansion was disabled, libml2 was still fetching external entities. This still made it vulnerable to certain XML eXternal Entity (XXE) issues such as DoS attacks or firewall circumvention, but would not allow easy information leak. The above fix was applied to libxml2 packages in Red Hat Enterprise Linux 6 via RHSA-2012:1288: https://rhn.redhat.com/errata/RHSA-2012-1288.html Note that the libxml2 packages for Red Hat Enterprise Linux 5 released via the same erratum did not get the same fix. The above commit only resolved the issue for general entities. Similar problem was found to affect processing of parameter entities and got the CVE-2014-0191 assigned, see bug 1090976.