On February 27, 2013, the ModSecurity project team was notified by security researchers from Positive Technologies that they had identified an XXE flaw in ModSecurity. Here is the CWE info for XXE -
Libxml2 XXE CVEs
The vulnerability lies within Libxml2 itself and was recently identified on public mail-list and assigned CVEs - http://seclists.org/oss-sec/2013/q1/391
Libxml2 in ModSecurity
ModSecurity inspects XML request bodies by leveraging the libxml2 parser. When ModSecurity is compiled with XML support, it can be activated for use by using the following example rule from the OWASP ModSecurity CRS -
# -- [[ Enable XML Body Parsing ]] -------------------------------------------------------
# The rules in this file will trigger the XML parser upon an XML request
# Initiate XML Processor in case of xml content-type
SecRule REQUEST_HEADERS:Content-Type "text/xml" \
SecRule REQBODY_PROCESSOR "!@streq XML" \
With this rule activated, when ModSecurity receives a request with an XML Content-Type body, it would call up the libxml2 code to parse the data and populate the XML variable for use in any rules.
Libxml2 in other Projects
Other projects that rely upon the Libxml2 parser for analyzing XML data are most likely also effected. For instance, Positive Technologies also open a very similar bug report for Eclipse here. The bug report includes example attack/testing payloads as well.
Additionally, PHP also had to deal with this issue and they chose to have a configurable option called - libxml_disable_entity_loader.
We chose to follow PHP's method of addressing this issue and we released ModSecurity v2.7.3 on March 29th that fixed the issue with addition of the SecXmlExternalEntity directive. This setting is Off by default but it allows the ModSecurity user to control XXE for the libxml2 parser. It is highly recommended that organizations using ModSecurity either upgrade to v2.7.3 and set SecXmlExternalEntity Off or disable the XML request body parser rule entirely.