1. Introduction
An XML External Entity attack targets applications that process XML input. It happens when a parser handles XML data containing references to external resources without proper security checks. This can lead to confidential data being exposed, denial of service attacks, and potentially allow attackers to scan internal networks from the server processing the XML. The primary impact is on confidentiality, with potential for integrity and availability issues.
2. Technical Explanation
The attack occurs because the XML parser attempts to resolve external entities defined within the XML document or referenced DTDs (Document Type Definitions). If not configured correctly, this allows an attacker to include arbitrary files from the server’s filesystem or access internal network resources. The Common Weakness Enumeration (CWE) identifier for this issue is CWE-611. An example attack involves crafting a malicious XML document with an entity pointing to sensitive system files like /etc/passwd.
- Root cause: Weakly configured XML parser allowing external entity resolution.
- Exploit mechanism: Attackers supply XML input containing references to external entities, which the parser resolves leading to data disclosure or other impacts. For example, an attacker could include a DTD that defines an entity pointing to a local file.
- Scope: Applications using XML parsers without appropriate security measures are affected. This includes many programming languages and platforms.
3. Detection and Assessment
Confirming vulnerability involves checking the parser configuration and testing with malicious XML input. A quick check is to identify the XML parsing library in use.
- Quick checks: Identify the version of the XML parser used by your application.
- Scanning: Static analysis tools can detect vulnerable XML parsers, but may produce false positives.
- Logs and evidence: Look for errors related to external entity resolution or file access attempts in application logs.
# Example command placeholder:
# Identify the version of libxml2 on a Linux system
libxml2-config --version
4. Solution / Remediation Steps
The primary solution is to configure the XML processor to disallow external entity resolution and use local static DTDs.
4.1 Preparation
- Ensure you have a rollback plan in case of issues. A simple revert of the config file should suffice.
- Change windows may be needed for critical applications, requiring approval from relevant teams.
4.2 Implementation
- Step 1: Configure your XML parser to disable external entity resolution. This is usually done through a configuration setting or property.
- Step 2: Ensure the parser only uses local static DTDs and does not attempt to load DTDs from remote URLs.
4.3 Config or Code Example
Before
# Python example using xml.etree.ElementTree without disabling external entities
import xml.etree.ElementTree as ET
tree = ET.parse('malicious.xml')
root = tree.getroot()
After
# Python example using xml.etree.ElementTree with disabling external entities
import xml.etree.ElementTree as ET
from lxml import etree
def parse_xml(xml_string):
parser = etree.XMLParser(resolve_entities=False)
tree = etree.fromstring(xml_string, parser=parser)
return tree
tree = parse_xml('malicious.xml')
root = tree.getroot()
4.4 Security Practices Relevant to This Vulnerability
Practices that directly address this vulnerability type include input validation and secure defaults.
- Practice 2: Using safe default configurations for XML parsers, such as disabling external entity resolution, reduces the risk of exploitation.
4.5 Automation (Optional)
If suitable, provide a small script or infrastructure code that applies the fix at scale. Only include if safe and directly relevant.
# Example Ansible task to update XML parser configuration file
- name: Disable external entity resolution in XML parser config
lineinfile:
path: /etc/xmlparser/config.conf
regexp: '^resolve_entities = True$'
line: 'resolve_entities = False'
notify: Restart XML Parser Service
5. Verification / Validation
- Post-fix check: Attempt to parse a known malicious XML file and verify that no external entities are resolved.
- Re-test: Re-run the earlier detection method (e.g., parsing the malicious XML) to confirm the issue is gone. The parser should not resolve any external entities.
- Monitoring: Monitor application logs for errors related to external entity resolution, which could indicate a regression or misconfiguration.
# Post-fix command and expected output (Python example)
import xml.etree.ElementTree as ET
try:
tree = ET.parse('malicious.xml') # Should raise an exception if external entities are disabled
except Exception as e:
print("External entity resolution blocked successfully:", e)
6. Preventive Measures and Monitoring
Update security baselines to include XML parser configuration settings that disable external entity resolution. Add checks in CI/CD pipelines to validate XML input.
- Baselines: Update your security baseline or policy to require disabling external entity resolution for all XML parsers.
- Pipelines: Integrate static analysis tools into your CI/CD pipeline to detect vulnerable XML configurations and malicious XML input.
- Asset and patch process: Regularly review and update the configuration of XML parsers on critical systems.
7. Risks, Side Effects, and Roll Back
- Risk or side effect 1: Applications relying on external entities may stop functioning correctly.
- Risk or side effect 2: Incorrect configuration could leave the system vulnerable.
- Roll back: Revert the XML parser configuration to its original state. Restart any affected services.
8. References and Resources
Link only to sources that match this exact vulnerability. Use official advisories and trusted documentation.
- Vendor advisory or bulletin: Check your specific XML parser vendor’s website for relevant security advisories.
- NVD or CVE entry: https://nvd.nist.gov/vuln/detail/CVE-2013-2251
- Product or platform documentation relevant to the fix: Consult your XML parser’s documentation for instructions on disabling external entity resolution.