PostgreSQL JDBC Driver (aka PgJDBC) before 42.2.13 allows XXE. Reference: https://jdbc.postgresql.org/documentation/changelog.html#version_42.2.13 Upstream commit: https://github.com/pgjdbc/pgjdbc/commit/14b62aca4764d496813f55a43d050b017e01eb65
More info from the reporters blog - https://blog.daviddworken.com/posts/pgjdbc-xxe/
We disagree with some aspects of this base flaw's scoring and suggest the following corrections Exploitability Metrics: Attack Vector Network (AV:N) - Agree here, we cannot say we control the contents of the database, this could be XML (and DTD injection) derived from unsanitized input Attack Complexity Low (AC:L) - Changed to Attack Complexity High (AC:H) We have to assume the vulnerable component (SQLXML) is being used and specialized access conditions or extenuating circumstances do not exist for the read side of the attack however the caveat to this is the injection side of the flaw has elements outside the attackers control * The attacker must have a method of injecting malicious XML into the database (unsanitized user input) * The field type in the table must be typed as XML Privileges Required None (PR:N) - Agree here, the attacker does not need to be a privileged user eg. no login required to exploit the base flaw, again a caveat that we cannot take into scope is they will need to populate the postgres db table. User Interaction None (UI:N) Agree here, a user does not need to be coerced into performing any action for this flaw, an attacker can expect the XML contained in the postgress DB to be parsed by the default document reader. Scope Unchanged (S:U) Agree here, the attacker will not be able to escape the scope of the executing JVM solely due to this flaw Impact Metrics: Confidentiality High (C:H) Agree in principle here, the default xml parser will execute with the privileges of the JVM and any files accessible to it with the same permissions can be exfiltrated - The caveat being that depending on the implemntation and setup of the XML parser exfiltration can often be limited to single line strings and non-special files, using alternative protocols for exfiltration can often bypass these limitations Integrity High (I:H) - Changed to Integrity Low (I:L) Agree in principle here, as there is possibility for SSRF and in some rare circumstances RCE via XXE but the latter requires very specific configuration which is outside of the attackers control, modification of data is possible, but the attacker does not have control over the consequence of a modification * SSRF relies on external services to the postgresql jdbc driver on the target host * RCE again relies on the presence of certain URL handlers and known attacks normally rely on some elements of SSRF Availability High (A:I) Agree here, there is presitent for DoS attacks such as billion laughs attack as well as the likely event of the parser throwing an exception and exiting the application when parsing invalid XML
Marking AMQ Online as Low impact, this is because although the postgresql jdbc driver is shipped as part of the Technology Preview IoT functionality, it does not use, or support, the XML datatype field/SQLXML implementation, we believe this is a necessary factor for vulnerability to be practically exploitable.
This issue has been addressed in the following products: Red Hat Integration Debezium 1.1.3 Via RHSA-2020:3005 https://access.redhat.com/errata/RHSA-2020:3005
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-13692
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2020:3176 https://access.redhat.com/errata/RHSA-2020:3176
Created postgresql-jdbc tracking bugs for this issue: Affects: fedora-all [bug 1861447]
This issue has been addressed in the following products: Red Hat AMQ Online 1.5.2 GA Via RHSA-2020:3209 https://access.redhat.com/errata/RHSA-2020:3209
This issue has been addressed in the following products: Red Hat build of Quarkus 1.3.4 SP1 Via RHSA-2020:3248 https://access.redhat.com/errata/RHSA-2020:3248
The fix for this issue disables processing of external entities and DTDs. This change can possibly introduce a problem in deployments where processing of external entities or DTDs is required to properly parse values read from the database. The following Red Hat Knowledgebase article describes how to re-enabled the functionality disabled by this fix: https://access.redhat.com/articles/5266441 Note: Re-enabling processing of external entities and DTDs also re-introduces this security issue. It should only be used when database only stores fully trusted XML documents.
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.0 Update Services for SAP Solutions Via RHSA-2020:3283 https://access.redhat.com/errata/RHSA-2020:3283
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.1 Extended Update Support Via RHSA-2020:3286 https://access.redhat.com/errata/RHSA-2020:3286
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2020:3284 https://access.redhat.com/errata/RHSA-2020:3284
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2020:3285 https://access.redhat.com/errata/RHSA-2020:3285
This issue has been addressed in the following products: Red Hat Decision Manager Via RHSA-2020:3675 https://access.redhat.com/errata/RHSA-2020:3675
This issue has been addressed in the following products: Red Hat Process Automation Via RHSA-2020:3678 https://access.redhat.com/errata/RHSA-2020:3678
This issue has been addressed in the following products: Red Hat Fuse 7.8.0 Via RHSA-2020:5568 https://access.redhat.com/errata/RHSA-2020:5568
This issue has been addressed in the following products: Red Hat Integration - Camel K - Tech-Preview 2 Via RHSA-2021:0110 https://access.redhat.com/errata/RHSA-2021:0110