CVE Vulnerabilities

CVE-2022-46751

XML Injection (aka Blind XPath Injection)

Published: Aug 21, 2023 | Modified: Nov 21, 2024
CVSS 3.x
8.2
HIGH
Source:
NVD
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:L
CVSS 2.x
RedHat/V2
RedHat/V3
8.2 MODERATE
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:L
Ubuntu

Improper Restriction of XML External Entity Reference, XML Injection (aka Blind XPath Injection) vulnerability in Apache Software Foundation Apache Ivy.This issue affects any version of Apache Ivy prior to 2.5.2.

When Apache Ivy prior to 2.5.2 parses XML files - either its own configuration, Ivy files or Apache Maven POMs - it will allow downloading external document type definitions and expand any entity references contained therein when used.

This can be used to exfiltrate data, access resources only the machine running Ivy has access to or disturb the execution of Ivy in different ways.

Starting with Ivy 2.5.2 DTD processing is disabled by default except when parsing Maven POMs where the default is to allow DTD processing but only to include a DTD snippet shipping with Ivy that is needed to deal with existing Maven POMs that are not valid XML files but are nevertheless accepted by Maven. Access can be be made more lenient via newly introduced system properties where needed.

Users of Ivy prior to version 2.5.2 can use Java system properties to restrict processing of external DTDs, see the section about JAXP Properties for External Access restrictions inside Oracles Java API for XML Processing (JAXP) Security Guide.

Weakness

The product does not properly neutralize special elements that are used in XML, allowing attackers to modify the syntax, content, or commands of the XML before it is processed by an end system.

Affected Software

Name Vendor Start Version End Version
Ivy Apache * 2.5.2 (excluding)
MTA-6.2-RHEL-8 RedHat mta/mta-rhel8-operator:6.2.2-3 *
MTA-6.2-RHEL-9 RedHat mta/mta-hub-rhel9:6.2.2-2 *
MTA-6.2-RHEL-9 RedHat mta/mta-operator-bundle:6.2.2-5 *
MTA-6.2-RHEL-9 RedHat mta/mta-pathfinder-rhel9:6.2.2-2 *
MTA-6.2-RHEL-9 RedHat mta/mta-ui-rhel9:6.2.2-2 *
MTA-6.2-RHEL-9 RedHat mta/mta-windup-addon-rhel9:6.2.2-3 *
MTR 1.2.4 RedHat apache-ivy *
Red Hat AMQ Streams 2.6.0 RedHat apache-ivy *
RHINT Camel-Springboot 4.0.0 RedHat apache-ivy *

Potential Mitigations

  • Assume all input is malicious. Use an “accept known good” input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, “boat” may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as “red” or “blue.”
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code’s environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

References