Git Product home page Git Product logo

sql-jdbc's Introduction

OpenSearch - JDBC

This is the driver for JDBC connectivity to a cluster running with OpenSearch SQL support.

JDBC Driver

Build JDBC CI

Specifications

The driver is compatible with JDBC 4.2 specification and requires a minimum of Java 8.

BI Tool Connectors

Download and Installation

The driver is available for download from Maven, from Artifacts page on OpenSearch.org at the very bottom and from automated CI workflow.

Using the driver

The driver comes in the form of a single jar file. To use it, simply place it on the classpath of the Java application that needs to use it.

If using with JDBC compatible BI tools, refer to the tool documentation on configuring a new JDBC driver. Typically, all that's required is to make the tool aware of the location of the driver jar and then use it to setup database (i.e OpenSearch) connections.

Connection URL and other settings

To setup a connection, the driver requires a JDBC connection URL. The connection URL is of the form:

    jdbc:opensearch://[scheme://][host][:port][/context-path]?[property-key=value]&[property-key2=value2]..&[property-keyN=valueN]
  • scheme

    Can be one of http or https. Default is http.

  • host

    Hostname or IP address of the target cluster. Default is localhost.

  • port

    Port number on which the cluster's REST interface is listening. Default value depends on the scheme selected. For http, the default is 9200. For https, the default is 443.

  • context-path

    The context path at which the cluster REST interface is rooted. Not needed if the REST interface is simply available on the '/' context path.

  • property key=value

    The query string portion of the connection URL can contain desired connection settings in the form of one or more property-key=value pairs. The possible configuration properties are provided in the table below. The property keys and values are case insensitive and values unless otherwise indicated.

    Note that JDBC provides multiple APIs for specifying connection properties of which specifying them in the connection URL is just one. When directly coding with the driver you can choose any of the other options (refer sample code below). If you are setting up a connection via a tool, it is likely the tool will allow you to specify the connection URL (with just the scheme, host, port and context-path components) while the the connection properties are provided separately. For example, you may not wish to place the user and password in the connection URL. Check the tool you are using for such support.

    The configurable connection properties are:

    Property Key Description Accepted Value(s) Default value
    user Connection username. mandatory if auth property selects a authentication scheme that mandates a username value any string null
    password Connection password. mandatory if auth property selects a authentication scheme that mandates a password value any string null
    fetchSize Cursor page size positive integer value. Max value is limited by index.max_result_window OpenSearch setting 0 (for non-paginated response)
    logOutput Location where driver logs should be emitted a valid file path null (logs are disabled)
    logLevel Severity level for which driver logs should be emitted in order from highest (least logging) to lowest (most logging): OFF, FATAL, ERROR, WARN, INFO, DEBUG, TRACE, ALL OFF (logs are disabled)
    auth Authentication mechanism to use NONE (no auth), BASIC (HTTP Basic), AWS_SIGV4 (AWS SIGV4) basic if username and/or password is specified, NONE otherwise
    awsCredentialsProvider The AWS credential provider to be used when authentication mechanism is AWS_SIGV4 (AWS SIGV4). If not set, the driver will use DefaultAWSCredentialsProviderChain to sign the request. The value has to be an instance of com.amazonaws.auth.AWSCredentialsProvider instance of an AWSCredentialProvider DefaultAWSCredentialsProviderChain
    region If authentication type is aws_sigv4, then this is the region value to use when signing requests. Only needed if the driver can not determine the region for the host endpoint. The driver will detect the region if the host endpoint matches a known url pattern. a valid AWS region value e.g. us-east-1 null (auto-detected if possible from the host endpoint)
    requestCompression Whether to indicate acceptance of compressed (gzip) responses when making server requests true or false false
    useSSL Whether to establish the connection over SSL/TLS true or false false if scheme is http, true if scheme is https
    trustStoreLocation Location of the SSL/TLS truststore to use file path or URL as appropriate to the type of truststore null
    trustStoreType Type of the truststore valid truststore type recognized by available Java security providers JKS
    trustStorePassword Password to access the Trust Store any string null
    keyStoreLocation Location of the SSL/TLS keystore to use file path or URL as appropriate to the type of keystore null
    keyStoreType Type of the keystore valid keystore type recognized by available Java security providers JKS
    keyStorePassword Password to access the keystore any string null
    trustSelfSigned Shortcut way to indicate that any self-signed certificate should be accepted. A truststore is not required to be configured. true or false false
    hostnameVerification Indicate whether certificate hostname verification should be performed when using SSL/TLS true or false true
    tunnelHost VPC endpoint hostname if connected through a tunnel or proxy and AWS_SIGV4 authentication is used any string null

Connecting using the DriverManager interface

The main Driver class is org.opensearch.jdbc.Driver. If the driver jar is on the application classpath, no other configuration is required.

Code samples to open a connection for some typical scenarios are given below:

  • Connect to localhost on port 9200 with no authentication over a plain connection
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.Statement;


String url = "jdbc:opensearch://localhost:9200";

Connection con = DriverManager.getConnection(url);
Statement st = con.createStatement();

// use the connection

// close connection
con.close();
  • Connect to a remote host on default SSL port with no authentication
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.Statement;


String url = "jdbc:opensearch://https://remote-host-name";

Connection con = DriverManager.getConnection(url);
Statement st = con.createStatement();

// use the connection

// close connection
con.close();

or,

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.Statement;


String url = "jdbc:opensearch://remote-host-name";

Properties properties = new Properties();
properties.put("useSSL", "true");

Connection con = DriverManager.getConnection(url, properties);
Statement st = con.createStatement();

// use the connection

// close connection
con.close();
  • Connect to a remote host with HTTP Basic authentication over an SSL/TLS connection on the default SSL/TLS port. Note - if a username and password are provided and auth property is not provided, basic auth is implicitly used.
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.Statement;


String url = "jdbc:opensearch://https://remote-host-name";
String user = "username";
String password = "password";

Connection con = DriverManager.getConnection(url, user, password);
Statement st = con.createStatement();

// use the connection

// close connection
con.close();

or,

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.Statement;


String url = "jdbc:opensearch://remote-host-name";

Properties properties = new Properties();
properties.put("useSSL", "true");
properties.put("user", "username");
properties.put("password", "password");

Connection con = DriverManager.getConnection(url, properties);
Statement st = con.createStatement();

// use the connection

// close connection
con.close();
  • Connect to a remote host with HTTP Basic authentication over an SSL/TLS connection, allowing any self-signed certificate and optionally turning off hostname verification. This may be useful for a dev/test setup.
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.Statement;


String url = "jdbc:opensearch://remote-host-name";

Properties properties = new Properties();
properties.put("useSSL", "true");
properties.put("trustSelfSigned", "true");

// uncomment below to turn off hostname verification
// properties.put("hostnameVerification", "false");

properties.put("user", "username");
properties.put("password", "password");

Connection con = DriverManager.getConnection(url, properties);
Statement st = con.createStatement();

// use the connection

// close connection
con.close();
  • Connect to a remote host on default SSL port with AWS Sig V4 authentication. The driver will determine the credentials used to sign the request just like the standard aws-sdk i.e. in standard directories, environment variables etc.
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.Statement;


String url = "jdbc:opensearch://https://remote-host-name?auth=aws_sigv4";

Connection con = DriverManager.getConnection(url);
Statement st = con.createStatement();

// use the connection

// close connection
con.close();

or,

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.Statement;


String url = "jdbc:opensearch://https://remote-host-name";

Properties properties = new Properties();
properties.put("auth", "aws_sigv4");

Connection con = DriverManager.getConnection(url, properties);
Statement st = con.createStatement();

// use the connection

// close connection
con.close();
  • Connect to a remote host on default SSL port with AWS Sig V4 authentication, explicitly specifying the AWSCredentialProvider to use
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.Statement;


String url = "jdbc:opensearch://https://remote-host-name";

Properties properties = new Properties();
properties.put("awsCredentialsProvider", new EnvironmentVariableCredentialsProvider());

Connection con = DriverManager.getConnection(url, properties);
Statement st = con.createStatement();

// use the connection

// close connection
con.close();
  • Connect to a remote host on default SSL port with AWS Sig V4 authentication, explicitly specifying the region to use in the request signing.
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.Statement;


String url = "jdbc:opensearch://https://remote-host-name?auth=aws_sigv4&region=us-west-1";

Connection con = DriverManager.getConnection(url);
Statement st = con.createStatement();

// use the connection

// close connection
con.close();

or,

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.Statement;


String url = "jdbc:opensearch://https://remote-host-name";

Properties properties = new Properties();
properties.put("auth", "aws_sigv4");
properties.put("region", "us-west-2");

Connection con = DriverManager.getConnection(url, properties);
Statement st = con.createStatement();

// use the connection

// close connection
con.close();

Connecting using the DataSource interface

The driver also provides a javax.sql.DataSource implementation via the org.opensearch.jdbc.OpenSearchDataSource class that can be used to obtain a connection. Here are some typical code samples:

  • Connect to localhost on port 9200 with no authentication over a plain connection
import java.sql.Connection;
import java.sql.Statement;
import javax.sql.DataSource;

import org.opensearch.jdbc.OpenSearchDataSource;


String url = "jdbc:opensearch://localhost:9200";

OpenSearchDataSource ds = new OpenSearchDataSource();
ds.setUrl(url);

Connection con = ds.getConnection(url);
Statement st = con.createStatement();

// use the connection

// close connection
con.close();
  • Connect to a remote host on default SSL port with no authentication
import java.sql.Connection;
import java.sql.Statement;
import javax.sql.DataSource;

import org.opensearch.jdbc.OpenSearchDataSource;


String url = "jdbc:opensearch://https://remote-host-name";

OpenSearchDataSource ds = new OpenSearchDataSource();
ds.setUrl(url);

Connection con = ds.getConnection(url);
Statement st = con.createStatement();

// use the connection

// close connection
con.close();
  • Connect to a remote host with HTTP Basic authentication over an SSL/TLS connection on the default SSL/TLS port.
import java.sql.Connection;
import java.sql.Statement;
import javax.sql.DataSource;

import org.opensearch.jdbc.OpenSearchDataSource;


String url = "jdbc:opensearch://https://remote-host-name";

OpenSearchDataSource ds = new OpenSearchDataSource();
ds.setUrl(url);

Connection con = ds.getConnection(url, "user", "password");
Statement st = con.createStatement();

// use the connection

// close connection
con.close();
  • Connect to a remote host on default SSL port with AWS Sig V4 authentication. The driver will determine the credentials used to sign the request just like the standard aws-sdk i.e. in standard directories, environment variables etc.
import java.sql.Connection;
import java.sql.Statement;
import javax.sql.DataSource;

import org.opensearch.jdbc.OpenSearchDataSource;


String url = "jdbc:opensearch://https://remote-host-name?auth=aws_sigv4";

OpenSearchDataSource ds = new OpenSearchDataSource();
ds.setUrl(url);

Connection con = ds.getConnection(url);
Statement st = con.createStatement();

// use the connection

// close connection
con.close();
  • Connect to a remote host on default SSL port with AWS Sig V4 authentication, explicitly specifying the AWSCredentialProvider to use
import java.sql.Connection;
import java.sql.Statement;
import javax.sql.DataSource;

import org.opensearch.jdbc.OpenSearchDataSource;


String url = "jdbc:opensearch://https://remote-host-name?auth=aws_sigv4&region=us-west-1";

OpenSearchDataSource ds = new OpenSearchDataSource();
ds.setUrl(url);
ds.setAwsCredentialProvider(new EnvironmentVariableCredentialsProvider());

Connection con = ds.getConnection(url);
Statement st = con.createStatement();

// use the connection

// close connection
con.close();
  • Connect to a remote host on default SSL port with AWS Sig V4 authentication, explicitly specifying the region to use in the request signing.
import java.sql.Connection;
import java.sql.Statement;
import javax.sql.DataSource;

import org.opensearch.jdbc.OpenSearchDataSource;


String url = "jdbc:opensearch://https://remote-host-name?auth=aws_sigv4&region=us-west-1";

OpenSearchDataSource ds = new OpenSearchDataSource();
ds.setUrl(url);

Connection con = ds.getConnection(url);
Statement st = con.createStatement();

// use the connection

// close connection
con.close();

Building from source

The driver is built as a shadow jar so that its dependencies are bundled within itself. This way no additional libraries besides the driver jar need to be placed on an application classpath for the driver to be used. The namespaces of the bundled dependencies are modified to ensure they do not conflict with other classes on the application classpath.

Run unit tests and build the driver jar

./gradlew clean test shadowJar

Build the driver jar without unit tests

./gradlew shadowJar

Publish the built driver jar to local maven repo

./gradlew publishToMavenLocal

Documentation

Please refer to the documentation for detailed information on installing and configuring OpenSearch.

Code of Conduct

This project has adopted an Open Source Code of Conduct.

Security issue notifications

If you discover a potential security issue in this project we ask that you notify AWS/Amazon Security via our vulnerability reporting page. Please do not create a public GitHub issue.

Licensing

See the LICENSE file for our project's licensing. We will ask you to confirm the licensing of your contribution.

Copyright

Copyright OpenSearch Contributors. See NOTICE for details.

sql-jdbc's People

Contributors

acarbonetto avatar akuzin1 avatar amazon-auto avatar anirudha avatar chloe-zh avatar dai-chen avatar davidcui1225 avatar dblock avatar derek-ho avatar eugenesk24 avatar gaiksaya avatar gumpacg avatar joshuali925 avatar kavithacm avatar margarit-h avatar mend-for-github-com[bot] avatar mengweieric avatar nocharger avatar penghuo avatar peterzhuamazon avatar ps48 avatar reta avatar tengda-he avatar vamsi-amazon avatar yang-db avatar yury-fridlyand avatar zhongnansu avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

sql-jdbc's Issues

wiremock-2.27.2.jar: 7 vulnerabilities (highest severity is: 9.8) - autoclosed

Vulnerable Library - wiremock-2.27.2.jar

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-http/9.2.28.v20190418/9fdb0a88275bdb191fa8399f23fc6b39fafb7348/jetty-http-9.2.28.v20190418.jar

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Vulnerabilities

CVE Severity CVSS Dependency Type Fixed in (wiremock version) Remediation Available
CVE-2021-23369 High 9.8 handlebars-4.0.7.jar Transitive N/A*
CVE-2017-7657 High 9.8 jetty-http-9.2.28.v20190418.jar Transitive N/A*
CVE-2017-7656 High 7.5 jetty-http-9.2.28.v20190418.jar Transitive N/A*
CVE-2021-28165 High 7.5 jetty-io-9.2.28.v20190418.jar Transitive N/A*
CVE-2020-27216 High 7.0 jetty-webapp-9.2.28.v20190418.jar Transitive N/A*
CVE-2021-28169 Medium 5.3 detected in multiple dependencies Transitive N/A*
CVE-2021-29425 Medium 4.8 commons-io-2.2.jar Transitive N/A*

*For some transitive vulnerabilities, there is no version of direct dependency with a fix. Check the section "Details" below to see if there is a version of transitive dependency where vulnerability is fixed.

Details

CVE-2021-23369

Vulnerable Library - handlebars-4.0.7.jar

Logic-less and semantic templates with Java

Library home page: https://github.com/jknack/handlebars.java

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/com.github.jknack/handlebars/4.0.7/98489d468d97297e9a363f2119bd0b20ad9bed67/handlebars-4.0.7.jar

Dependency Hierarchy:

  • wiremock-2.27.2.jar (Root Library)
    • handlebars-4.0.7.jar (Vulnerable Library)

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Found in base branch: main

Vulnerability Details

The package handlebars before 4.7.7 are vulnerable to Remote Code Execution (RCE) when selecting certain compiling options to compile templates coming from an untrusted source.

Publish Date: 2021-04-12

URL: CVE-2021-23369

CVSS 3 Score Details (9.8)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: High
    • Integrity Impact: High
    • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-23369

Release Date: 2021-04-12

Fix Resolution: com.github.jknack:handlebars:4.2.0, handlebars - 4.7.7

CVE-2017-7657

Vulnerable Library - jetty-http-9.2.28.v20190418.jar

Administrative parent pom for Jetty modules

Library home page: http://www.eclipse.org/jetty

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-http/9.2.28.v20190418/9fdb0a88275bdb191fa8399f23fc6b39fafb7348/jetty-http-9.2.28.v20190418.jar

Dependency Hierarchy:

  • wiremock-2.27.2.jar (Root Library)
    • jetty-proxy-9.2.28.v20190418.jar
      • jetty-client-9.2.28.v20190418.jar
        • jetty-http-9.2.28.v20190418.jar (Vulnerable Library)

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Found in base branch: main

Vulnerability Details

In Eclipse Jetty, versions 9.2.x and older, 9.3.x (all configurations), and 9.4.x (non-default configuration with RFC2616 compliance enabled), transfer-encoding chunks are handled poorly. The chunk length parsing was vulnerable to an integer overflow. Thus a large chunk size could be interpreted as a smaller chunk size and content sent as chunk body could be interpreted as a pipelined request. If Jetty was deployed behind an intermediary that imposed some authorization and that intermediary allowed arbitrarily large chunks to be passed on unchanged, then this flaw could be used to bypass the authorization imposed by the intermediary as the fake pipelined request would not be interpreted by the intermediary as a request.

Publish Date: 2018-06-26

URL: CVE-2017-7657

CVSS 3 Score Details (9.8)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: High
    • Integrity Impact: High
    • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://bugs.eclipse.org/bugs/show_bug.cgi?id=535668

Release Date: 2018-06-26

Fix Resolution: org.eclipse.jetty:jetty-server:9.3.24.v20180605,9.4.11.v20180605;org.eclipse.jetty:jetty-http:9.3.24.v20180605,9.4.11.v20180605

CVE-2017-7656

Vulnerable Library - jetty-http-9.2.28.v20190418.jar

Administrative parent pom for Jetty modules

Library home page: http://www.eclipse.org/jetty

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-http/9.2.28.v20190418/9fdb0a88275bdb191fa8399f23fc6b39fafb7348/jetty-http-9.2.28.v20190418.jar

Dependency Hierarchy:

  • wiremock-2.27.2.jar (Root Library)
    • jetty-proxy-9.2.28.v20190418.jar
      • jetty-client-9.2.28.v20190418.jar
        • jetty-http-9.2.28.v20190418.jar (Vulnerable Library)

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Found in base branch: main

Vulnerability Details

In Eclipse Jetty, versions 9.2.x and older, 9.3.x (all configurations), and 9.4.x (non-default configuration with RFC2616 compliance enabled), HTTP/0.9 is handled poorly. An HTTP/1 style request line (i.e. method space URI space version) that declares a version of HTTP/0.9 was accepted and treated as a 0.9 request. If deployed behind an intermediary that also accepted and passed through the 0.9 version (but did not act on it), then the response sent could be interpreted by the intermediary as HTTP/1 headers. This could be used to poison the cache if the server allowed the origin client to generate arbitrary content in the response.

Publish Date: 2018-06-26

URL: CVE-2017-7656

CVSS 3 Score Details (7.5)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: None
    • Integrity Impact: High
    • Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://bugs.eclipse.org/bugs/show_bug.cgi?id=535667

Release Date: 2018-06-26

Fix Resolution: org.eclipse.jetty:jetty-server:9.2.25.v20180606,9.3.24.v20180605,9.4.11.v20180605;org.eclipse.jetty:jetty-http:9.2.25.v20180606.,9.3.24.v20180605,9.4.11.v20180605

CVE-2021-28165

Vulnerable Library - jetty-io-9.2.28.v20190418.jar

Administrative parent pom for Jetty modules

Library home page: http://www.eclipse.org/jetty

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-io/9.2.28.v20190418/b9219469ee48d03436684890acac89a1053afbcf/jetty-io-9.2.28.v20190418.jar

Dependency Hierarchy:

  • wiremock-2.27.2.jar (Root Library)
    • jetty-proxy-9.2.28.v20190418.jar
      • jetty-client-9.2.28.v20190418.jar
        • jetty-io-9.2.28.v20190418.jar (Vulnerable Library)

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Found in base branch: main

Vulnerability Details

In Eclipse Jetty 7.2.2 to 9.4.38, 10.0.0.alpha0 to 10.0.1, and 11.0.0.alpha0 to 11.0.1, CPU usage can reach 100% upon receiving a large invalid TLS frame.

Publish Date: 2021-04-01

URL: CVE-2021-28165

CVSS 3 Score Details (7.5)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: None
    • Integrity Impact: None
    • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-26vr-8j45-3r4w

Release Date: 2021-04-01

Fix Resolution: org.eclipse.jetty:jetty-io:9.4.39, org.eclipse.jetty:jetty-io:10.0.2, org.eclipse.jetty:jetty-io:11.0.2

CVE-2020-27216

Vulnerable Library - jetty-webapp-9.2.28.v20190418.jar

Jetty web application support

Library home page: http://www.eclipse.org/jetty

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-webapp/9.2.28.v20190418/c55fc40b7f018f28fd282eb51547c6ae5732d076/jetty-webapp-9.2.28.v20190418.jar

Dependency Hierarchy:

  • wiremock-2.27.2.jar (Root Library)
    • jetty-webapp-9.2.28.v20190418.jar (Vulnerable Library)

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Found in base branch: main

Vulnerability Details

In Eclipse Jetty versions 1.0 thru 9.4.32.v20200930, 10.0.0.alpha1 thru 10.0.0.beta2, and 11.0.0.alpha1 thru 11.0.0.beta2O, on Unix like systems, the system's temporary directory is shared between all users on that system. A collocated user can observe the process of creating a temporary sub directory in the shared temporary directory and race to complete the creation of the temporary subdirectory. If the attacker wins the race then they will have read and write permission to the subdirectory used to unpack web applications, including their WEB-INF/lib jar files and JSP files. If any code is ever executed out of this temporary directory, this can lead to a local privilege escalation vulnerability.

Publish Date: 2020-10-23

URL: CVE-2020-27216

CVSS 3 Score Details (7.0)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Local
    • Attack Complexity: High
    • Privileges Required: Low
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: High
    • Integrity Impact: High
    • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://bugs.eclipse.org/bugs/show_bug.cgi?id=567921

Release Date: 2020-10-23

Fix Resolution: org.eclipse.jetty:jetty-runner:9.4.33,10.0.0.beta3,11.0.0.beta3;org.eclipse.jetty:jetty-webapp:9.4.33,10.0.0.beta3,11.0.0.beta3

CVE-2021-28169

Vulnerable Libraries - jetty-servlets-9.2.28.v20190418.jar, jetty-http-9.2.28.v20190418.jar

jetty-servlets-9.2.28.v20190418.jar

Utility Servlets from Jetty

Library home page: http://www.eclipse.org/jetty

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-servlets/9.2.28.v20190418/c31256a26ce3527058ae96f0b5f780c9462f469f/jetty-servlets-9.2.28.v20190418.jar

Dependency Hierarchy:

  • wiremock-2.27.2.jar (Root Library)
    • jetty-servlets-9.2.28.v20190418.jar (Vulnerable Library)

jetty-http-9.2.28.v20190418.jar

Administrative parent pom for Jetty modules

Library home page: http://www.eclipse.org/jetty

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-http/9.2.28.v20190418/9fdb0a88275bdb191fa8399f23fc6b39fafb7348/jetty-http-9.2.28.v20190418.jar

Dependency Hierarchy:

  • wiremock-2.27.2.jar (Root Library)
    • jetty-proxy-9.2.28.v20190418.jar
      • jetty-client-9.2.28.v20190418.jar
        • jetty-http-9.2.28.v20190418.jar (Vulnerable Library)

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Found in base branch: main

Vulnerability Details

For Eclipse Jetty versions <= 9.4.40, <= 10.0.2, <= 11.0.2, it is possible for requests to the ConcatServlet with a doubly encoded path to access protected resources within the WEB-INF directory. For example a request to /concat?/%2557EB-INF/web.xml can retrieve the web.xml file. This can reveal sensitive information regarding the implementation of a web application.

Publish Date: 2021-06-09

URL: CVE-2021-28169

CVSS 3 Score Details (5.3)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: Low
    • Integrity Impact: None
    • Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-gwcr-j4wh-j3cq

Release Date: 2021-06-09

Fix Resolution: org.eclipse.jetty:jetty-runner:9.4.41.v20210516, 10.0.3, 11.0.3, org.eclipse.jetty:jetty-http:9.4.41.v20210516, 10.0.3, 11.0.3,org.eclipse.jetty:jetty-servlets:9.4.41.v20210516, 10.0.3, 11.0.3, org.eclipse.jetty:jetty-server:9.4.41.v20210516, 10.0.3, 11.0.3

CVE-2021-29425

Vulnerable Library - commons-io-2.2.jar

The Commons IO library contains utility classes, stream implementations, file filters, file comparators, endian transformation classes, and much more.

Library home page: http://commons.apache.org/io/

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/commons-io/commons-io/2.2/83b5b8a7ba1c08f9e8c8ff2373724e33d3c1e22a/commons-io-2.2.jar

Dependency Hierarchy:

  • wiremock-2.27.2.jar (Root Library)
    • commons-fileupload-1.4.jar
      • commons-io-2.2.jar (Vulnerable Library)

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Found in base branch: main

Vulnerability Details

In Apache Commons IO before 2.7, When invoking the method FileNameUtils.normalize with an improper input string, like "//../foo", or "\..\foo", the result would be the same value, thus possibly providing access to files in the parent directory, but not further above (thus "limited" path traversal), if the calling code would use the result to construct a path value.

Publish Date: 2021-04-13

URL: CVE-2021-29425

CVSS 3 Score Details (4.8)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: High
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: Low
    • Integrity Impact: Low
    • Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29425

Release Date: 2021-04-13

Fix Resolution: commons-io:commons-io:2.7

[BUG] `getColumnTypeName` for timestamp depends on cursor on/off

What is the bug?

getColumnTypeName for timestamp depends whether cursor feature is active

How can one reproduce the bug?

Steps to reproduce the behavior:

  1. Create an index and a doc:
curl -s -H 'Content-Type: application/json' -XPUT "http://localhost:9200/date_type_index?pretty" -d '{"mappings": {"properties": {"release_date": {"type": "date" }}}}'
curl -s -H 'Content-Type: application/json' -XPOST "http://localhost:9200/date_type_index/_doc?pretty" -d '{"release_date": "2022-11-16"}'
  1. Query it without cursor:
Connection conn = driver.connect(connStr, properties);
Statement stmt = conn.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY);
ResultSet rs = stmt.executeQuery("select * from date_type_index");
ResultSetMetaData rsmd = rs.getMetaData();
String typeName = rsmd.getColumnTypeName("release_date");
  1. typeName is TIMESTAMP
  2. Query it with cursor:
Connection conn = driver.connect(connStr, properties);
Statement stmt = conn.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY);
stmt.setFetchSize(5);
ResultSet rs = stmt.executeQuery("select * from date_type_index");
ResultSetMetaData rsmd = rs.getMetaData();
String typeName = rsmd.getColumnTypeName("release_date");
  1. typeName is DATE

What is the expected behavior?

It should be always timestamp since SQL plugin reports this type:

{
  "schema": [
    {
      "name": "release_date",
      "type": "timestamp"
    }
  ],
  "datarows": [
    [
      "2022-11-16 00:00:00"
    ]
  ],
  "total": 1,
  "size": 1,
  "status": 200
}

What is your host/environment?

  • OpenSearch 2.5
  • JDBC 5e8d914 @ main

Do you have any screenshots?

N/A

Do you have any additional context?

Thanks @akuzin1 for reporting that

[FEATURE] Support preemptive basic auth in JDBC driver

Is your feature request related to a problem?
Currently basic auth is non-preemptive that expect an authenticate header (WWW-Authenticate: Basic ...) from the server. There is problem when server responds something else, for example, an OpenSearch cluster with SAML enabled returns WWW-Authenticate: X-Security-IdP instead. This fails the basic auth request with a 401 HTTP error.

What solution would you like?
One solution is switch to preemptive auth and enforce it all the time. The impact of this needs to be evaluated carefully.

What alternatives have you considered?
Alternatively, provide a configuration for user to choose which auth mode to use. This may be safer and more flexible option compared with enforcing preemptive auth.

Do you have any additional context?

  1. Non-/Preemptive process in brief: https://stackoverflow.com/questions/7482523/preemptive-authentication-why
  2. The HTTP RFC: https://datatracker.ietf.org/doc/html/rfc2617
  3. Sample HTTP 401 error as below
HttpResponseProxy{HTTP/1.1 401 Unauthorized [Date: Thu, 23 Jun 2022 17:22:31 GMT, Content-Type: text/plain;charset=UTF-8, Content-Length: 0, Connection: keep-alive, Access-Control-Allow-Origin: *, WWW-Authenticate: X-Security-IdP realm="OpenSearch Security"

[FEATURE] Add ask-for-approval mechanism to release workflow

Is your feature request related to a problem?
Add automatic mechanism to GHA which asks for release approvals.

What solution would you like?
See examples: https://github.com/opensearch-project/sql-odbc/blob/main/.github/workflows/release-drafter.yml and https://github.com/opensearch-project/spring-data-opensearch/blame/8522b6031a7e2aa8e1d720a6ff7992ad91cee501/.github/workflows/release-drafter.yml#L14-L27.
It creates an automatic issue like this one to get approvals.

What alternatives have you considered?
N/A

Do you have any additional context?
N/A

json-smart-2.4.8.jar: 1 vulnerabilities (highest severity is: 7.5) - autoclosed

Vulnerable Library - json-smart-2.4.8.jar

JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language.

Library home page: https://urielch.github.io/

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/net.minidev/json-smart/2.4.8/7c62f5f72ab05eb54d40e2abf0360a2fe9ea477f/json-smart-2.4.8.jar

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Vulnerabilities

CVE Severity CVSS Dependency Type Fixed in (json-smart version) Remediation Available
CVE-2023-1370 High 7.5 json-smart-2.4.8.jar Direct 2.4.9

Details

CVE-2023-1370

Vulnerable Library - json-smart-2.4.8.jar

JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language.

Library home page: https://urielch.github.io/

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/net.minidev/json-smart/2.4.8/7c62f5f72ab05eb54d40e2abf0360a2fe9ea477f/json-smart-2.4.8.jar

Dependency Hierarchy:

  • json-smart-2.4.8.jar (Vulnerable Library)

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Found in base branch: main

Vulnerability Details

Json-smart is a performance focused, JSON processor lib. When reaching a ‘[‘ or ‘{‘ character in the JSON input, the code parses an array or an object respectively. It was discovered that the code does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause a stack exhaustion (stack overflow) and crash the software.

Publish Date: 2023-03-22

URL: CVE-2023-1370

CVSS 3 Score Details (7.5)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: None
    • Integrity Impact: None
    • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://research.jfrog.com/vulnerabilities/stack-exhaustion-in-json-smart-leads-to-denial-of-service-when-parsing-malformed-json-xray-427633/

Release Date: 2023-03-22

Fix Resolution: 2.4.9

⛑️ Automatic Remediation is available for this issue


⛑️ Automatic Remediation is available for this issue.

[FEATURE] Update 1-click release process to publish shadow jar as well

Is your feature request related to a problem?
Currently 1-click release process uploads artifacts to maven only. It should upload a signed shadow jar to artifact bucket as well.

What solution would you like?
Add uploading a signed shadow jar to artifact bucket as well.

What alternatives have you considered?
N/A

Do you have any additional context?
Refer to opensearch-project/opensearch-build#3614 and opensearch-project/sql-odbc#52

[FEATURE] Create integration test platform for JDBC driver

Is your feature request related to a problem?

There are automated tests for JDBC driver with a real OpenSearch cluster

What solution would you like?

  1. New or modified CI workflow which run an OpenSearch cluster and run tests
  2. New test sub-project which loads and tests JDBC driver

What alternatives have you considered?

N/A

Do you have any additional context?

N/A

[FEATURE] Support SSH tunnel with AWS_SIGv4 auth

Is your feature request related to a problem?
An OpenSearch cluster located into AWS VPC can be reached with SSH tunnel or VPN only.
AWS_SIGv4 authentication requires extra header to set if SSH tunnel is used.

What solution would you like?
Add optional configuration parameter when AWS_SIGv4 is selected.

What alternatives have you considered?
Use BASIC auth instead.

Do you have any additional context?
https://stackoverflow.com/a/67683064
opensearch-project/sql-odbc#41

Request to publish the repository to Maven

Is your feature request related to a problem? Please describe.
All of our projects use Maven for dependency management and we would love if the OpenSearch project is published to maven. For example: This will enable us to use OpenSearch - JDBC in our projects.

Describe the solution you'd like
Publishing the library to Maven

Implementation of isValid for the JDBC driver

Is your feature request related to a problem? Please describe.
The lack of implementation of isValid() may be the root cause of inconsistencies in the TDVT test results.

Describe the solution you'd like
It would be great if isValid() is completely implemented similar to https://github.com/pgjdbc/pgjdbc/blob/bf00387461bafdf0f19a8557bff554e469207cce/pgjdbc/src/main/java/org/postgresql/jdbc/PgConnection.java so that it does not always return true.

Additional context
https://github.com/opensearch-project/sql/blob/main/sql-jdbc/src/main/java/org/opensearch/jdbc/ConnectionImpl.java#L421

[BUG] JDBC version is hardcoded in multiple places

What is the bug?
JDBC version is hardcoded in multiple places.

How can one reproduce the bug?
Steps to reproduce the behavior:

  1. Go to https://github.com/opensearch-project/sql/blob/2.x/sql-jdbc/src/main/java/org/opensearch/jdbc/internal/Version.java
  2. Go to https://github.com/opensearch-project/sql/blob/2.x/sql-jdbc/build.gradle
  3. See that they each have hardcoded versions for the jdbc driver

What is the expected behavior?
One should use the other's version in order to avoid version mismatch occurrences.

What is your host/environment?

  • OS: macOS
  • Version OpenSearch 2.4
  • Plugins

[FEATURE]Set additional params to server

Is your feature request related to a problem?
We want JDBC driver to work with multitenant Opensearch and use api key distinguish between tenants.

What solution would you like?
We need one custom parameter to be sent in every request to the server and we will have multitenant (access rights) proxy before Opensearch. Is it possible now? How? When I set custom parameter in jdbc url I do not see it being sent to the server.

What alternatives have you considered?
Using some other parameter e.g. user. But I couldn't see it sent to the server even when I set it up in jdbc params after port or as user. Or we can use context-path it is working.

h2-2.1.210.jar: 1 vulnerabilities (highest severity is: 7.8)

Vulnerable Library - h2-2.1.210.jar

H2 Database Engine

Library home page: https://h2database.com

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/com.h2database/h2/2.1.210/a7395ae43062f9237eb441137b789c518c7d4c2f/h2-2.1.210.jar

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Vulnerabilities

CVE Severity CVSS Dependency Type Fixed in (h2 version) Remediation Available
CVE-2022-45868 High 7.8 h2-2.1.210.jar Direct N/A

Details

CVE-2022-45868

Vulnerable Library - h2-2.1.210.jar

H2 Database Engine

Library home page: https://h2database.com

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/com.h2database/h2/2.1.210/a7395ae43062f9237eb441137b789c518c7d4c2f/h2-2.1.210.jar

Dependency Hierarchy:

  • h2-2.1.210.jar (Vulnerable Library)

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Found in base branch: main

Vulnerability Details

The web-based admin console in H2 Database Engine through 2.1.214 can be started via the CLI with the argument -webAdminPassword, which allows the user to specify the password in cleartext for the web admin console. Consequently, a local user (or an attacker that has obtained local access through some means) would be able to discover the password by listing processes and their arguments. NOTE: the vendor states "This is not a vulnerability of H2 Console ... Passwords should never be passed on the command line and every qualified DBA or system administrator is expected to know that."

Publish Date: 2022-11-23

URL: CVE-2022-45868

CVSS 3 Score Details (7.8)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Local
    • Attack Complexity: Low
    • Privileges Required: Low
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: High
    • Integrity Impact: High
    • Availability Impact: High

For more information on CVSS3 Scores, click here.

Baseline MAINTAINERS, CODEOWNERS, and external collaborator permissions

Follow opensearch-project/.github#125 to baseline MAINTAINERS, CODEOWNERS, and external collaborator permissions.

Close this issue when:

  1. MAINTAINERS.md has the correct list of project maintainers.
  2. CODEOWNERS exists and has the correct list of aliases.
  3. Repo permissions only contain individual aliases as collaborators with maintain rights, admin, and triage teams.
  4. All other teams are removed from repo permissions.

If this repo's permissions was already baselined, please confirm the above when closing this issue.

[BUG] Unable to run queries with DataGrip

What is the bug?
After setting up the JDBC driver in DataGrip I get inconsistent errors. See reproduction steps for details.

How can one reproduce the bug?
Steps to reproduce the behavior:

  • Download the JDBC driver here:
  • Open your IDE and open the "Database" section
  • Click "+" > "Driver"
  • Set the name to "OpenSearch"
  • On the "Driver Files" section select the JAR you just downloaded
  • In the class dropdown select org.opensearch.jdbc.Driver
  • Click "Ok"
  • Click "+" > "Data source" > "OpenSearch"
  • In the "General" tab:
    • Set "Authentication" to "No auth"
    • Hostname to the OS cluster address
  • In the "Advanced" tab set the following key/value pairs:
    • auth: AWS_SIGV4
    • region: The region the cluster is on
  • Test connection
  • Create a test index and put data in it

This is where the behaviors begin:

1234:hadesrodr...s-east-1> select * from hosts_rodrigof_metadata_hosts_2023-04-11
[2023-04-13 11:02:30] java.sql.SQLException
1234:hadesrodr...s-east-1> select * from hosts_rodrigof_metadata_hosts
[2023-04-13 11:08:29] java.sql.SQLException
1234:hadesrodr...s-east-1> select * from "hosts_rodrigof_metadata_hosts"
[2023-04-13 11:08:37] Error executing query
[2023-04-13 11:08:37] HTTP Code: 400. Message: Bad Request. Raw response received: {
[2023-04-13 11:08:37] "error": {
[2023-04-13 11:08:37] "reason": "Error occurred in OpenSearch engine: no such index [\"hosts_rodrigof_metadata_hosts\"]",
[2023-04-13 11:08:37] "details": "org.opensearch.index.IndexNotFoundException: no such index [\"hosts_rodrigof_metadata_hosts\"]\nFor more details, please send request for Json format to see the raw response from OpenSearch engine.",
[2023-04-13 11:08:37] "type": "IndexNotFoundException"
[2023-04-13 11:08:37] },
[2023-04-13 11:08:37] "status": 404
[2023-04-13 11:08:37] }
1234:hadesrodr...s-east-1> select * from "hosts_rodrigof_metadata_hosts_2023-04-11"
[2023-04-13 11:09:05] Error executing query
[2023-04-13 11:09:05] HTTP Code: 400. Message: Bad Request. Raw response received: {
[2023-04-13 11:09:05] "error": {
[2023-04-13 11:09:05] "reason": "Error occurred in OpenSearch engine: no such index [\"hosts_rodrigof_metadata_hosts_2023-04-11\"]",
[2023-04-13 11:09:05] "details": "org.opensearch.index.IndexNotFoundException: no such index [\"hosts_rodrigof_metadata_hosts_2023-04-11\"]\nFor more details, please send request for Json format to see the raw response from OpenSearch engine.",
[2023-04-13 11:09:05] "type": "IndexNotFoundException"
[2023-04-13 11:09:05] },
[2023-04-13 11:09:05] "status": 404
[2023-04-13 11:09:05] }

Where hosts_rodrigof_metadata_hosts_2023-04-11 is an index and hosts_rodrigof_metadata_hosts is an alias. However, using the Elasticsearch plugin, I can successfully run queries via HTTP:

POST /_plugins/_sql/
{
  "query": "select count(*) from hosts_rodrigof_metadata_hosts"
}

Returns: 
{
  "schema": [
    {
      "name": "count(*)",
      "type": "integer"
    }
  ],
  "datarows": [
    [
      12237733
    ]
  ],
  "total": 1,
  "size": 1,
  "status": 200
}

Something I have noticed is that the use of * doesn't work, for example:

select * from my_index

Fails with java.sql.SQLException, but:

select col1 from my_index

Does work.

What is the expected behavior?
Queries should run as expected when using the JDBC driver.

What is your host/environment?

  • OS: AWS
  • Version 2.3
  • Plugins: sql

Release SQL JDBC driver

Is your feature request related to a problem?

Moved issue from former repository

What solution would you like?

Publish most recent JDBC driver on Maven and on artifacts page.
Driver build is available as GHA artifact: https://github.com/opensearch-project/sql/actions/workflows/sql-jdbc-test-and-build-workflow.yml?query=branch%3A2.x

What alternatives have you considered?
N/A

Do you have any additional context?
Add any other context or screenshots about the feature request here.

[BUG] The JDBC driver reports incorrect precision of `TIMESTAMP`

What is the bug?

JDBC driver reports the precision of TIMESTAMP columns as 24 - which is incorrect

How can one reproduce the bug?

ResultSetMetaData::getPrecision
https://docs.oracle.com/javase/8/docs/api/java/sql/ResultSetMetaData.html#getPrecision-int-

What is the expected behavior?

For datetime datatypes, this is the length in characters of the String representation

For TIMESTAMP and DATETIME it should be 19 for 0 FSP and up to 29 for 9 FSP (fractional second digits).

What is your host/environment?

JDBC: 1.1.0.1

Do you have any additional context?

Opened on behalf of @kylepbit

[FEATURE] Specify AWS Profile, Secret Key or Access Key when using OpenSearch SQL JDBC Driver from a Database Client

Is your feature request related to a problem?
As an analyst, I would like to connect to Opensearch via a JDBC client such as DBeaver Community Edition.

Currently, the SQL JDBC Driver accepts the parameter auth to use AWS SIGV4.
In this case, the driver can then use an awsCredentialsProvider, which must be created separately. If not specified, the driver uses the default aws profile.
Within DBeaver, I cannot create an awsCredentialsProvider.

What solution would you like?
I would like to be able to use a custom named profile to connect, for example if I have a profile called awsdev or awsprod, I would like to supply this as a parameter to the driver to select which credentials to use, without creating a custom awsCredentialsProvider.

Alternatively, I would like to be able to supply an AWS Access Key and AWS Secret Access Key directly to the JDBC driver to be used.

These two options would allow easier use of the JDBC driver.

What alternatives have you considered?
I am currently researching solutions for creating a custom awsCredentialsProvider within DBeaver or otherwise, however this requires further research and seems unnecessarily laborious.

aws-java-sdk-core-1.11.452.jar: 1 vulnerabilities (highest severity is: 7.5) - autoclosed

Vulnerable Library - aws-java-sdk-core-1.11.452.jar

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/com.fasterxml.jackson.dataformat/jackson-dataformat-cbor/2.6.7/ba9e74b11135b18248e960df657a2b86ae77a079/jackson-dataformat-cbor-2.6.7.jar

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Vulnerabilities

CVE Severity CVSS Dependency Type Fixed in (aws-java-sdk-core version) Remediation Available
CVE-2020-28491 High 7.5 jackson-dataformat-cbor-2.6.7.jar Transitive 1.12.1

Details

CVE-2020-28491

Vulnerable Library - jackson-dataformat-cbor-2.6.7.jar

Support for reading and writing Concise Binary Object Representation ([CBOR](https://www.rfc-editor.org/info/rfc7049) encoded data using Jackson abstractions (streaming API, data binding, tree model)

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/com.fasterxml.jackson.dataformat/jackson-dataformat-cbor/2.6.7/ba9e74b11135b18248e960df657a2b86ae77a079/jackson-dataformat-cbor-2.6.7.jar

Dependency Hierarchy:

  • aws-java-sdk-core-1.11.452.jar (Root Library)
    • jackson-dataformat-cbor-2.6.7.jar (Vulnerable Library)

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Found in base branch: main

Vulnerability Details

This affects the package com.fasterxml.jackson.dataformat:jackson-dataformat-cbor from 0 and before 2.11.4, from 2.12.0-rc1 and before 2.12.1. Unchecked allocation of byte buffer can cause a java.lang.OutOfMemoryError exception.

Publish Date: 2021-02-18

URL: CVE-2020-28491

CVSS 3 Score Details (7.5)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: None
    • Integrity Impact: None
    • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28491

Release Date: 2021-02-18

Fix Resolution (com.fasterxml.jackson.dataformat:jackson-dataformat-cbor): 2.11.4

Direct dependency fix Resolution (com.amazonaws:aws-java-sdk-core): 1.12.1

⛑️ Automatic Remediation is available for this issue


⛑️ Automatic Remediation is available for this issue.

[BUG] Driver does not return SQLSTATE28000 for invalid username or password

What is the bug?
Tableau requires drivers to return SQLSTATE28000 for their manual QA test with invalid username and password.

How can one reproduce the bug?
Steps to reproduce the behavior:

  1. Open Tableau with the taco file in /Users/[user]/Documents/My Tableau Repository/Connectors
  2. Put the shadow jar in /Users/[user]/Library/Tableau/Drivers
  3. Log in with incorrect credentials
  4. See that the result is "Bad Connection"

What is the expected behavior?
Tableau expects the message to be "Invalid username or password"

What is your host/environment?

  • JDBC 1.3.0
  • SQL 2.8.0

Do you have any screenshots?
Current:
Screenshot 2023-06-15 at 11 20 50 AM

Expected:
Screenshot 2023-06-21 at 4 11 19 PM

[BUG] JDBC Driver reports DATE max size incorrectly

What is the bug?
The getDataTypes() call returns a row for the DATE type, and returns the max size as 24 instead of the correct 10. 24 is used for timestamp, not date.

How can one reproduce the bug?
Steps to reproduce the behavior:

  1. Connect to OpenSearch using the JDBC driver using any custom app or tool like DbVisualizer
  2. Open or invoke the data types
  3. Locate the DATE entry
  4. See the MAX_SIZE column reported as 24 instead of 10

What is the expected behavior?
The MAX_SIZE should be 10 instead of 24.

What is your host/environment?

  • OS: macOS Monterey
  • Version JDBC driver v 1.1.0.1
  • Plugins

[BUG] `ResultSet::getObject` fails for datetime types

What is the bug?

rs.getObject(column, LocalTime.class)

causes an exception:

java.sql.SQLDataException: Can not convert object '15:04:32' of type 'java.lang.String' to type 'java.time.LocalTime'
	at org.opensearch.jdbc.types.TypeConverter.objectConversionException(TypeConverter.java:38)
	at org.opensearch.jdbc.types.BaseTypeConverter.convert(BaseTypeConverter.java:53)
	at org.opensearch.jdbc.ResultSetImpl.getObjectX(ResultSetImpl.java:604)
	at org.opensearch.jdbc.ResultSetImpl.getObjectX(ResultSetImpl.java:595)
	at org.opensearch.jdbc.ResultSetImpl.getObject(ResultSetImpl.java:1436)

How can one reproduce the bug?

// load driver
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select time(sysdate())");
ResultSetMetaData rsmd = rs.getMetaData();
var columns = new HashMap<String, String>();
for (int i = 1; i <= rsmd.getColumnCount(); i++) {
  columns.put(rsmd.getColumnName(i), rsmd.getColumnTypeName(i));
}

while (rs.next()) {
  for (var col : columns.entrySet()) {
    Object value = null;
    switch (col.getValue()) {
    // other types handling
    case "TIME" : rs.getObject(col.getKey(), LocalTime.class); break; // <-- crash here
    default:
      throw new IllegalArgumentException(col.getValue());
   }
  }
}

What is the expected behavior?

Driver should be able to generate java.time classes.

What is your host/environment?

2.x @ e2bf2544

Do you have any screenshots?

N/A

Do you have any additional context?

N/A

JDBC Driver returns incorrect SQLState[BUG]

Describe the bug
The JDBC driver is not returning SQLSTATE 28000 with invalid username or password authorization.

To Reproduce
Steps to reproduce the behavior:

  1. Follow the steps in https://tableau.github.io/connector-plugin-sdk/docs/manual-test#:~:text=works%20as%20expected.-,Before%20you%20begin,-Be%20sure%20that
  2. Follow the steps in https://tableau.github.io/connector-plugin-sdk/docs/manual-test#:~:text=following%20these%20guidelines.-,On%20Tableau%20Desktop,-Launch%20Tableau%20Desktop
  3. Connect to 'OpenSearch by OpenSearch for ES'
  4. Input incorrect username and password authorization.
  5. See error that does not state invalid username or password

Expected behavior
The error should state that the username or password is invalid.

Additional context
According to https://tableau.github.io/connector-plugin-sdk/docs/manual-test#:~:text=Connect%20to%20the%20correct%20database%20with%20the%20wrong%20credentials, SQLSTATE 28000 is not being returned. Additional resource for SQLSTATES: https://tableau.github.io/connector-plugin-sdk/docs/drivers

[FEATURE] Support for geo_point type

Is your feature request related to a problem?
Tableau is not able to create visualizations as a column of type geo_point is converted to string as shown in the screenshot below.

What solution would you like?
When creating a visualization of type geo_point on Tableau, the driver should support queries generated by Tableau in order for Tableau to generate a map with dots to represent coordinates.

Screenshot 2023-06-27 at 2 18 45 PM

[BUG] Release workflow is missing 2PR approval process

Describe the bug

Adding this issue as bug because the current 1-click process in this repository lacks this feature. See details here opensearch-project/opensearch-build#3111
Sample PR: opensearch-project/opensearch-java#383

To Reproduce
Push a tag to this repo and release is drafted immediately. It should ask for approval before moving forward

Expected behavior
The release-drafter workflow should be blocked asking for approval from 2 maintainers/codewoners to approve the release.

jetty-server-11.0.12.jar: 1 vulnerabilities (highest severity is: 5.3) - autoclosed

Vulnerable Library - jetty-server-11.0.12.jar

The core jetty server artifact.

Library home page: https://eclipse.org/jetty

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-server/11.0.12/29c82ff7e059ee1e454af6d391834abadf24e60/jetty-server-11.0.12.jar

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Vulnerabilities

CVE Severity CVSS Dependency Type Fixed in (jetty-server version) Remediation Available
CVE-2023-26048 Medium 5.3 jetty-server-11.0.12.jar Direct 11.0.14

Details

CVE-2023-26048

Vulnerable Library - jetty-server-11.0.12.jar

The core jetty server artifact.

Library home page: https://eclipse.org/jetty

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-server/11.0.12/29c82ff7e059ee1e454af6d391834abadf24e60/jetty-server-11.0.12.jar

Dependency Hierarchy:

  • jetty-server-11.0.12.jar (Vulnerable Library)

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Found in base branch: main

Vulnerability Details

Jetty is a java based web server and servlet engine. In affected versions servlets with multipart support (e.g. annotated with @MultipartConfig) that call HttpServletRequest.getParameter() or HttpServletRequest.getParts() may cause OutOfMemoryError when the client sends a multipart request with a part that has a name but no filename and very large content. This happens even with the default settings of fileSizeThreshold=0 which should stream the whole part content to disk. An attacker client may send a large multipart request and cause the server to throw OutOfMemoryError. However, the server may be able to recover after the OutOfMemoryError and continue its service -- although it may take some time. This issue has been patched in versions 9.4.51, 10.0.14, and 11.0.14. Users are advised to upgrade. Users unable to upgrade may set the multipart parameter maxRequestSize which must be set to a non-negative value, so the whole multipart content is limited (although still read into memory).

Publish Date: 2023-04-18

URL: CVE-2023-26048

CVSS 3 Score Details (5.3)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: None
    • Integrity Impact: None
    • Availability Impact: Low

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-qw69-rqj8-6qw8

Release Date: 2023-04-18

Fix Resolution: 11.0.14

⛑️ Automatic Remediation is available for this issue


⛑️ Automatic Remediation is available for this issue.

[BUG] Broken link in the README

What is the bug?
Power BI link should be removed from the BI tools section of the readme. The link to the Tableau connector in the same section is broken and should be fixed.

[BUG] Driver handles incorrectly empty paging responses

What is the bug?

Driver handles incorrectly empty paging responses
Driver stops paging the cursor if response is empty. Criteria to stop paging is no cursor returned.

How can one reproduce the bug?

Check out and build SQL plugin from branch dev-pagination-v2_revE @ 163093cb76
Run query

select * from <table> limit 5, 5;

with page size (fetch_size) = 2. The tricky part is to have fetch_size less than offset.

Driver returns an empty result set.

What is the expected behavior?

Driver should scroll the cursor until received response has no cursor.

What is your host/environment?

1.2.0.0 from maven

[BUG] JDBC doesn't return second fraction part for timestamp

What is the bug?

Reason: manual parsing of timestamp values
https://github.com/opensearch-project/sql/blob/c923e80cd654ee8136c74180bf0bd6231044ff71/sql-jdbc/src/main/java/org/opensearch/jdbc/types/TimestampType.java#L63-L96

How can one reproduce the bug?

select timestamp("1970-01-01 12:00:00.501");

JDBC output:

image

SQL plugin output:

fetched rows / total rows = 73/73
+-------------------------+--------------------------------+
| val                     | key                            |
|-------------------------+--------------------------------|
| null                    | null                           |
| 1899-01-01 20:00:00     | 001: 1899-01-01 12:00:00       |
| 1899-12-31 20:00:00     | 002: 1899-12-31 12:00:00       |
| 1940-02-29 20:00:00     | 003: 1940-02-29 12:00:00       |
| 1970-01-01 08:00:00     | 004: 1970-01-01 00:00:00-epoch |
| 1970-01-01 08:00:01     | 005: 1970-01-01 00:00:01       |
| 1970-01-01 09:00:00     | 006: 1970-01-01 01:00:00       |
| 1970-01-01 09:59:00     | 007: 1970-01-01 01:59:00       |
| 1970-01-01 09:59:59     | 008: 1970-01-01 01:59:59       |
| 1970-01-01 10:00:00     | 009: 1970-01-01 02:00:00       |
| 1970-01-01 10:00:01     | 010: 1970-01-01 02:00:01       |
| 1970-01-01 10:30:00.1   | 011: 1970-01-01 02:30:00.1     |
| 1970-01-01 11:00:00.2   | 012: 1970-01-01 03:00:00.2     |
| 1970-01-01 12:00:00.3   | 013: 1970-01-01 04:00:00.3     |
| 1970-01-01 13:00:00.4   | 014: 1970-01-01 05:00:00.4     |
| 1970-01-01 14:00:00.5   | 015: 1970-01-01 06:00:00.5     |
| 1970-01-01 15:00:00.6   | 016: 1970-01-01 07:00:00.6     |
| 1970-01-01 16:00:00.7   | 017: 1970-01-01 08:00:00.7     |
| 1970-01-01 17:00:00.8   | 018: 1970-01-01 09:00:00.8     |
| 1970-01-01 18:00:00.9   | 019: 1970-01-01 10:00:00.9     |
| 1970-01-01 19:59:00.499 | 020: 1970-01-01 11:59:00.499   |
| 1970-01-01 19:59:59.5   | 021: 1970-01-01 11:59:59.500   |
| 1970-01-01 20:00:00.501 | 022: 1970-01-01 12:00:00.501   |

What is the expected behavior?

Use API for parsing, e.g. Timestamp.valueOf method:

java.sql.Timestamp.valueOf("1970-01-01 12:00:00.501") = 1970-01-01 12:00:00.501

What is your host/environment?

2.x @ e2bf2544

CVE patch

Is your feature request related to a problem?
Remediate CVE's

What solution would you like?
Remediate CVE's

What alternatives have you considered?
N/A

Do you have any additional context?
Add any other context or screenshots about the feature request here.

wiremock-3.0.0-beta-2.jar: 1 vulnerabilities (highest severity is: 3.9) - autoclosed

Vulnerable Library - wiremock-3.0.0-beta-2.jar

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-xml/11.0.14/30210aaf71149eb446ce9cb0b659472d0f7d1ab5/jetty-xml-11.0.14.jar

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Vulnerabilities

CVE Severity CVSS Dependency Type Fixed in (wiremock version) Remediation Possible**
WS-2023-0236 Low 3.9 jetty-xml-11.0.14.jar Transitive N/A*

*For some transitive vulnerabilities, there is no version of direct dependency with a fix. Check the "Details" section below to see if there is a version of transitive dependency where vulnerability is fixed.

**In some cases, Remediation PR cannot be created automatically for a vulnerability despite the availability of remediation

Details

WS-2023-0236

Vulnerable Library - jetty-xml-11.0.14.jar

The jetty xml utilities.

Library home page: https://eclipse.org/jetty

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-xml/11.0.14/30210aaf71149eb446ce9cb0b659472d0f7d1ab5/jetty-xml-11.0.14.jar

Dependency Hierarchy:

  • wiremock-3.0.0-beta-2.jar (Root Library)
    • jetty-webapp-11.0.14.jar
      • jetty-xml-11.0.14.jar (Vulnerable Library)

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Found in base branch: main

Vulnerability Details

XmlParser is vulnerable to XML external entity (XXE) vulnerability.
XmlParser is being used when parsing Jetty’s xml configuration files. An attacker might exploit this vulnerability in order to achieve SSRF or cause a denial of service. One possible scenario is importing a (remote) malicious WAR into a Jetty’s server, while the WAR includes a malicious web.xml. The vulnerability is patched in versions 10.0.16, 11.0.16, and 12.0.0.

Publish Date: 2023-07-10

URL: WS-2023-0236

CVSS 3 Score Details (3.9)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Local
    • Attack Complexity: High
    • Privileges Required: High
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: Low
    • Integrity Impact: Low
    • Availability Impact: Low

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-58qw-p7qm-5rvh

Release Date: 2023-07-10

Fix Resolution: org.eclipse.jetty:jetty-xml:10.0.16,11.0.16,12.0.0

[BUG] [JDBC] GetColumns fails with StringIndexOutOfBoundsException

What is the bug?

Listing columns from index ending with hyphen (example: people-detection-poc-) throws StringIndexOutOfBoundsException.

Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: 42
	at java.lang.String.charAt(String.java:658) ~[?:1.8.0_322]
	at com.amazon.opendistroforelasticsearch.jdbc.internal.util.SqlParser.locateCommentEnd(SqlParser.java:59) ~[SpaceNeedleOpendistroforelasticsearchJdbcDriver-1.x.jar:?]
	at com.amazon.opendistroforelasticsearch.jdbc.internal.util.SqlParser.countParameterMarkers(SqlParser.java:46) ~[SpaceNeedleOpendistroforelasticsearchJdbcDriver-1.x.jar:?]
	at com.amazon.opendistroforelasticsearch.jdbc.PreparedStatementImpl.<init>(PreparedStatementImpl.java:67) ~[SpaceNeedleOpendistroforelasticsearchJdbcDriver-1.x.jar:?]
	at com.amazon.opendistroforelasticsearch.jdbc.DatabaseMetaDataImpl$ColumnMetadataStatement.<init>(DatabaseMetaDataImpl.java:1220) ~[SpaceNeedleOpendistroforelasticsearchJdbcDriver-1.x.jar:?]
	at com.amazon.opendistroforelasticsearch.jdbc.DatabaseMetaDataImpl.getColumns(DatabaseMetaDataImpl.java:773) ~[SpaceNeedleOpendistroforelasticsearchJdbcDriver-1.x.jar:?]

What is the expected behavior?
Driver should have handled it and return column details.

What is your host/environment?

  • OS: [e.g. iOS]
  • Version [e.g. 22]
  • Plugins

Do you have any screenshots?
If applicable, add screenshots to help explain your problem.

Do you have any additional context?
Add any other context about the problem.

[CVE] jetty CVE

What is the bug?
The project uses jetty version 11.0.14 while the versions with fixes are not yet available.

From workflow:

CVE Severity CVSS Score Vulnerable Library Suggested Fix Issue
WS-2023-0236Path to dependency file: /build.gradlePath to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-xml/11.0.14/30210aaf71149eb446ce9cb0b659472d0f7d1ab5/jetty-xml-11.0.14.jarDependency Hierarchy:-> wiremock-3.0.0-beta-2.jar (Root Library)   -> jetty-webapp-11.0.14.jar     -> ❌ jetty-xml-11.0.14.jar (Vulnerable Library) Low 3.9 jetty-xml-11.0.14.jar Upgrade to version: org.eclipse.jetty:jetty-xml:10.0.16,11.0.16,12.0.0 #59

CVE Severity CVSS Score Vulnerable Library Suggested Fix Issue
WS-2023-0236
Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-xml/11.0.14/30210aaf71149eb446ce9cb0b659472d0f7d1ab5/jetty-xml-11.0.14.jar

Dependency Hierarchy:

-> wiremock-3.0.0-beta-2.jar (Root Library)

-> jetty-webapp-11.0.14.jar

 -> ❌ jetty-xml-11.0.14.jar (Vulnerable Library)

Low 3.9 jetty-xml-11.0.14.jar Upgrade to version: org.eclipse.jetty:jetty-xml:10.0.16,11.0.16,12.0.0 #59

httpclient-4.5.13.jar: 1 vulnerabilities (highest severity is: 6.5) - autoclosed

Vulnerable Library - httpclient-4.5.13.jar

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/commons-codec/commons-codec/1.11/3acb4705652e16236558f0f4f2192cc33c3bd189/commons-codec-1.11.jar

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Vulnerabilities

CVE Severity CVSS Dependency Type Fixed in (httpclient version) Remediation Available
WS-2019-0379 Medium 6.5 commons-codec-1.11.jar Transitive N/A*

*For some transitive vulnerabilities, there is no version of direct dependency with a fix. Check the section "Details" below to see if there is a version of transitive dependency where vulnerability is fixed.

Details

WS-2019-0379

Vulnerable Library - commons-codec-1.11.jar

The Apache Commons Codec package contains simple encoder and decoders for various formats such as Base64 and Hexadecimal. In addition to these widely used encoders and decoders, the codec package also maintains a collection of phonetic encoding utilities.

Path to dependency file: /build.gradle

Path to vulnerable library: /home/wss-scanner/.gradle/caches/modules-2/files-2.1/commons-codec/commons-codec/1.11/3acb4705652e16236558f0f4f2192cc33c3bd189/commons-codec-1.11.jar

Dependency Hierarchy:

  • httpclient-4.5.13.jar (Root Library)
    • commons-codec-1.11.jar (Vulnerable Library)

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Found in base branch: main

Vulnerability Details

Apache commons-codec before version “commons-codec-1.13-RC1” is vulnerable to information disclosure due to Improper Input validation.

Publish Date: 2019-05-20

URL: WS-2019-0379

CVSS 3 Score Details (6.5)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: Low
    • Integrity Impact: Low
    • Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Release Date: 2019-05-20

Fix Resolution: commons-codec:commons-codec:1.13

OpenSearch JDBC driver - Error parsing root / intermediate nodes of the JSON - Compatibility with Tableau

Is Opensearch 1.2.4 along with JDBC driver 1.1.0.1 compatible for retrieving and analysing data in Tableau?

I tried this JDBC driver in DbVisualizer and there are errors parsing columns of type OBJET, Unknown Type (2.002), these are the root / intermediate nodes of the fetched JSON records, that prevents the rest of the columns to show correctly. This does not happen, it woks properly, in an ElasticSearch with license and Elastic JDBC driver.

My guess is that the problem lies in the JDBC side, OpenSearch JDBC driver is missing something to properly parse fetched JSON records, relative to root / intermediate nodes. Maybe ElasticSearch JDBC Driver is ignoring them and only parses final nodes to columns.

View image:

Opensearch [Opensearch 1.2.4 + Opensearch JDBC Driver 1.1.0.1]:

Elastic [ElasticSearch JDBC Driver + ElasticSearch with license]

549dab5eb42e4df71fce460cae636c81dc53089f

[BUG] ResultSet.getTime(index, calendar) returns null

What is the bug?
Retrieving time with a calendar always returns null.

How can one reproduce the bug?
Steps to reproduce the behavior:

  1. Have some time data
  2. Invoke ResultSet.getTime(index, calendar) to try and get the time
  3. See null as the result, always

Looking at the code, it's simply hardcoded to return null.

What is the expected behavior?
A non-null value reflecting the retrieved time.

What is your host/environment?

  • OS: macOS
  • Version JDBC 1.1.0.1
  • Plugins

[BUG] JDBC driver forces SQL plugin to use the v1 engine

What is the bug?
Users of the JDBC driver cannot make use of new SQL plugin features because queries sent by the JDBC driver by-pass v2 engine and are always executed by the v1 engine.

What is the expected behavior?
Queries sent by JDBC driver to be attempted by v2 engine first and only fallback to v1 engine if it uses unsupported SQL features.

What is your host/environment?

  • OpenSearch 2.4.0.0
  • JDBC Driver 1.1.0.1

Do you have any additional context?
When JDBC executes a statement, it sets fetch_size parameter to 100. This fails this check here.

[BUG] Connect DBVisualizer to OpenSearch

Describe the bug
In Dbvisualizer 23.1 cant see geo datatype data from opensearch connection

To Reproduce

  1. Go to dbvisiualizer
  2. Click on add driver
  3. add jdbc driver
  4. make connection
  5. open sql worksheet

SELECT
*
FROM
opensearch_dashboards_sample_data_flights;

Columns OriginLocation and DestLocation are null , all others are filled

Expected behavior
no errors all columns shown

Plugins

Screenshots

Host/Environment (please complete the following information):

  • OS: Windows 11

Additional context
Docker developer container - dev tools works fine..
image
image
image

jetty-server-9.2.28.v20190418.jar: 3 vulnerabilities (highest severity is: 9.8) - autoclosed

Vulnerable Library - jetty-server-9.2.28.v20190418.jar

The core jetty server artifact.

Library home page: http://www.eclipse.org/jetty

Path to dependency file: /build.gradle

Path to vulnerable library: /radle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-server/9.2.28.v20190418/a6064a590340d4a19d9209d527f2b1ee2592bbe9/jetty-server-9.2.28.v20190418.jar,/home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-server/9.2.28.v20190418/a6064a590340d4a19d9209d527f2b1ee2592bbe9/jetty-server-9.2.28.v20190418.jar

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Vulnerabilities

CVE Severity CVSS Dependency Type Fixed in (jetty-server version) Remediation Available
CVE-2017-7657 High 9.8 jetty-server-9.2.28.v20190418.jar Direct 9.3.24.v20180605
CVE-2021-28169 Medium 5.3 jetty-server-9.2.28.v20190418.jar Direct 9.4.41.v20210516
CVE-2021-34428 Low 3.5 jetty-server-9.2.28.v20190418.jar Direct 9.3.30.v20211001

Details

CVE-2017-7657

Vulnerable Library - jetty-server-9.2.28.v20190418.jar

The core jetty server artifact.

Library home page: http://www.eclipse.org/jetty

Path to dependency file: /build.gradle

Path to vulnerable library: /radle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-server/9.2.28.v20190418/a6064a590340d4a19d9209d527f2b1ee2592bbe9/jetty-server-9.2.28.v20190418.jar,/home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-server/9.2.28.v20190418/a6064a590340d4a19d9209d527f2b1ee2592bbe9/jetty-server-9.2.28.v20190418.jar

Dependency Hierarchy:

  • jetty-server-9.2.28.v20190418.jar (Vulnerable Library)

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Found in base branch: main

Vulnerability Details

In Eclipse Jetty, versions 9.2.x and older, 9.3.x (all configurations), and 9.4.x (non-default configuration with RFC2616 compliance enabled), transfer-encoding chunks are handled poorly. The chunk length parsing was vulnerable to an integer overflow. Thus a large chunk size could be interpreted as a smaller chunk size and content sent as chunk body could be interpreted as a pipelined request. If Jetty was deployed behind an intermediary that imposed some authorization and that intermediary allowed arbitrarily large chunks to be passed on unchanged, then this flaw could be used to bypass the authorization imposed by the intermediary as the fake pipelined request would not be interpreted by the intermediary as a request.

Publish Date: 2018-06-26

URL: CVE-2017-7657

CVSS 3 Score Details (9.8)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: High
    • Integrity Impact: High
    • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://bugs.eclipse.org/bugs/show_bug.cgi?id=535668

Release Date: 2018-06-26

Fix Resolution: 9.3.24.v20180605

⛑️ Automatic Remediation is available for this issue

CVE-2021-28169

Vulnerable Library - jetty-server-9.2.28.v20190418.jar

The core jetty server artifact.

Library home page: http://www.eclipse.org/jetty

Path to dependency file: /build.gradle

Path to vulnerable library: /radle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-server/9.2.28.v20190418/a6064a590340d4a19d9209d527f2b1ee2592bbe9/jetty-server-9.2.28.v20190418.jar,/home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-server/9.2.28.v20190418/a6064a590340d4a19d9209d527f2b1ee2592bbe9/jetty-server-9.2.28.v20190418.jar

Dependency Hierarchy:

  • jetty-server-9.2.28.v20190418.jar (Vulnerable Library)

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Found in base branch: main

Vulnerability Details

For Eclipse Jetty versions <= 9.4.40, <= 10.0.2, <= 11.0.2, it is possible for requests to the ConcatServlet with a doubly encoded path to access protected resources within the WEB-INF directory. For example a request to /concat?/%2557EB-INF/web.xml can retrieve the web.xml file. This can reveal sensitive information regarding the implementation of a web application.

Publish Date: 2021-06-09

URL: CVE-2021-28169

CVSS 3 Score Details (5.3)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: Low
    • Integrity Impact: None
    • Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-gwcr-j4wh-j3cq

Release Date: 2021-06-09

Fix Resolution: 9.4.41.v20210516

⛑️ Automatic Remediation is available for this issue

CVE-2021-34428

Vulnerable Library - jetty-server-9.2.28.v20190418.jar

The core jetty server artifact.

Library home page: http://www.eclipse.org/jetty

Path to dependency file: /build.gradle

Path to vulnerable library: /radle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-server/9.2.28.v20190418/a6064a590340d4a19d9209d527f2b1ee2592bbe9/jetty-server-9.2.28.v20190418.jar,/home/wss-scanner/.gradle/caches/modules-2/files-2.1/org.eclipse.jetty/jetty-server/9.2.28.v20190418/a6064a590340d4a19d9209d527f2b1ee2592bbe9/jetty-server-9.2.28.v20190418.jar

Dependency Hierarchy:

  • jetty-server-9.2.28.v20190418.jar (Vulnerable Library)

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Found in base branch: main

Vulnerability Details

For Eclipse Jetty versions <= 9.4.40, <= 10.0.2, <= 11.0.2, if an exception is thrown from the SessionListener#sessionDestroyed() method, then the session ID is not invalidated in the session ID manager. On deployments with clustered sessions and multiple contexts this can result in a session not being invalidated. This can result in an application used on a shared computer being left logged in.

Publish Date: 2021-06-22

URL: CVE-2021-34428

CVSS 3 Score Details (3.5)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Physical
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: Low
    • Integrity Impact: Low
    • Availability Impact: None

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: GHSA-m6cp-vxjx-65j6

Release Date: 2021-06-22

Fix Resolution: 9.3.30.v20211001

⛑️ Automatic Remediation is available for this issue


⛑️ Automatic Remediation is available for this issue.

jackson-databind-2.13.3.jar: 2 vulnerabilities (highest severity is: 7.5) - autoclosed

Vulnerable Library - jackson-databind-2.13.3.jar

General data-binding functionality for Jackson: works on core streaming API

Library home page: http://github.com/FasterXML/jackson

Path to dependency file: /build.gradle

Path to vulnerable library: /radle/caches/modules-2/files-2.1/com.fasterxml.jackson.core/jackson-databind/2.13.3/56deb9ea2c93a7a556b3afbedd616d342963464e/jackson-databind-2.13.3.jar,/home/wss-scanner/.gradle/caches/modules-2/files-2.1/com.fasterxml.jackson.core/jackson-databind/2.13.3/56deb9ea2c93a7a556b3afbedd616d342963464e/jackson-databind-2.13.3.jar

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Vulnerabilities

CVE Severity CVSS Dependency Type Fixed in (jackson-databind version) Remediation Available
CVE-2022-42004 High 7.5 jackson-databind-2.13.3.jar Direct 2.13.4
CVE-2022-42003 High 7.5 jackson-databind-2.13.3.jar Direct 2.13.4.1

Details

CVE-2022-42004

Vulnerable Library - jackson-databind-2.13.3.jar

General data-binding functionality for Jackson: works on core streaming API

Library home page: http://github.com/FasterXML/jackson

Path to dependency file: /build.gradle

Path to vulnerable library: /radle/caches/modules-2/files-2.1/com.fasterxml.jackson.core/jackson-databind/2.13.3/56deb9ea2c93a7a556b3afbedd616d342963464e/jackson-databind-2.13.3.jar,/home/wss-scanner/.gradle/caches/modules-2/files-2.1/com.fasterxml.jackson.core/jackson-databind/2.13.3/56deb9ea2c93a7a556b3afbedd616d342963464e/jackson-databind-2.13.3.jar

Dependency Hierarchy:

  • jackson-databind-2.13.3.jar (Vulnerable Library)

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Found in base branch: main

Vulnerability Details

In FasterXML jackson-databind before 2.13.4, resource exhaustion can occur because of a lack of a check in BeanDeserializer._deserializeFromArray to prevent use of deeply nested arrays. An application is vulnerable only with certain customized choices for deserialization.

Publish Date: 2022-10-02

URL: CVE-2022-42004

CVSS 3 Score Details (7.5)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: None
    • Integrity Impact: None
    • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Release Date: 2022-10-02

Fix Resolution: 2.13.4

⛑️ Automatic Remediation is available for this issue

CVE-2022-42003

Vulnerable Library - jackson-databind-2.13.3.jar

General data-binding functionality for Jackson: works on core streaming API

Library home page: http://github.com/FasterXML/jackson

Path to dependency file: /build.gradle

Path to vulnerable library: /radle/caches/modules-2/files-2.1/com.fasterxml.jackson.core/jackson-databind/2.13.3/56deb9ea2c93a7a556b3afbedd616d342963464e/jackson-databind-2.13.3.jar,/home/wss-scanner/.gradle/caches/modules-2/files-2.1/com.fasterxml.jackson.core/jackson-databind/2.13.3/56deb9ea2c93a7a556b3afbedd616d342963464e/jackson-databind-2.13.3.jar

Dependency Hierarchy:

  • jackson-databind-2.13.3.jar (Vulnerable Library)

Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda

Found in base branch: main

Vulnerability Details

In FasterXML jackson-databind before 2.14.0-rc1, resource exhaustion can occur because of a lack of a check in primitive value deserializers to avoid deep wrapper array nesting, when the UNWRAP_SINGLE_VALUE_ARRAYS feature is enabled. Additional fix version in 2.13.4.1 and 2.12.17.1

Publish Date: 2022-10-02

URL: CVE-2022-42003

CVSS 3 Score Details (7.5)

Base Score Metrics:

  • Exploitability Metrics:
    • Attack Vector: Network
    • Attack Complexity: Low
    • Privileges Required: None
    • User Interaction: None
    • Scope: Unchanged
  • Impact Metrics:
    • Confidentiality Impact: None
    • Integrity Impact: None
    • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Release Date: 2022-10-02

Fix Resolution: 2.13.4.1

⛑️ Automatic Remediation is available for this issue


⛑️ Automatic Remediation is available for this issue.

[Release] Resign JDBC driver and Tableau Connector before 2031-11-09

Is your feature request related to a problem?
The JDBC driver and Tableau Connector signature timestamp expires in 2031-11-09. Tableau users won't be able to use the jar and taco past this date without signing the artifacts.

What solution would you like?
This is a tracking issue in the case that no new artifacts are released before the expiration date. Release the artifacts with a new valid timestamp.

Do you have any additional context?
More information on Tableau requirements here.

Appears that Struct is not a supported data type [BUG]

What is the bug?
Attempted to extract Struct (by calling resultSet.getObject(<fieldName>)) on returned ResultSet from JDBC driver and received the following error java.sql.SQLException: Conversion from OBJECT not supported.

The following is what the mapping of my index looks like:

"mappings": {
  "properties": {
    "details": {
      "properties": {
        "memory": {
          "type": "long"
        },
        "model": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          }
        }
      }
    },
    "item": {
      "type": "text",
      "fields": {
        "keyword": {
          "type": "keyword",
          "ignore_above": 256
        }
      }
    },
    "price": {
      "properties": {
        "currency": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          }
        },
        "value": {
          "type": "long"
        }
      }
    }
  }
}

Result set has the following columns:

  1. Column 1 of type VARCHAR and name: item
  2. Column 2 of type STRUCT and Name: details
  3. Column 3 of type STRUCT and Name: price

How can one reproduce the bug?
Steps to reproduce the behavior:

  1. Create an index with a struct or nested struct
  2. Execute a query using the JDBC driver
  3. Attempt to extract data from ResultSet by calling resultSet.getObject(<fieldName>) or resultSet.getObject(<fieldName>, <xxx.class>)
  4. See error mentioned above

What is the expected behavior?
It is expected to be able to retrieve the struct data type from the current row of the ResultSet, the same way other data types can be accessed.

What is your host/environment?

  • OS: Lambda Function with Java 11 (Corretto) Runtime
  • Version: JDBC Driver version 1.2.0.0

[BUG] No corresponding type for geo_point in JDBC driver

Describe the bug

JDBC driver throws NPE when result set includes fields of geo_point type. This seems caused by no mapping for geo_point type in https://github.com/opensearch-project/sql/blob/develop/sql-jdbc/src/main/java/org/opensearch/jdbc/types/OpenSearchType.java#L70.

The missing info can also be seen in user manual: https://github.com/opensearch-project/sql/blob/main/docs/user/general/datatypes.rst#data-types-mapping

To Reproduce
Steps to reproduce the behavior:

  1. Create the data flights sample index by OpenSearch Dashboards
  2. Run the query SELECT * FROM opensearch_dashboards_sample_data_flights
  3. See error

Expected behavior
Expect JDBC driver can handle properly and display geo point field values well as others.

Screenshots

Screen Shot 2021-06-01 at 12 06 57 PM

Host/Environment (please complete the following information):

  • OS: [e.g. iOS]
  • Version [e.g. 22]

Additional context
Error logs in JDBC driver:

2021-06-01 11:55:55.139 FINE   336 [ExecutorRunner-pool-2-thread-2 - d.i] Error (java.lang.NullPointerException) getting value for: 92/3 (java.lang.String: OriginLocation): java.lang.NullPointerException
2021-06-01 11:55:55.139 FINE   336 [ExecutorRunner-pool-2-thread-2 - d.i] 
java.lang.NullPointerException
	at org.opensearch.jdbc.ResultSetImpl.getObjectX(ResultSetImpl.java:600)
	at org.opensearch.jdbc.ResultSetImpl.getObjectX(ResultSetImpl.java:594)
	at org.opensearch.jdbc.ResultSetImpl.getStringX(ResultSetImpl.java:224)
	at org.opensearch.jdbc.ResultSetImpl.getString(ResultSetImpl.java:218)
	at com.onseven.dbvis.jdbc.c.d.c(Z:2630)
	at com.onseven.dbvis.jdbc.c.d.i(Z:2996)
	at com.onseven.dbvis.l.f.x.b(Z:848)
	at com.onseven.dbvis.l.f.x.b(Z:3226)
	at com.onseven.dbvis.l.f.l.c(Z:3200)
	at com.onseven.dbvis.l.f.l.b(Z:268)
	at com.onseven.dbvis.l.f.l.d(Z:2456)
	at com.onseven.dbvis.l.f.l.qe(Z:2750)
	at com.onseven.dbvis.l.f.r.qe(Z:2062)
	at com.onseven.dbvis.l.f.cb.ie(Z:236)
	at com.onseven.dbvis.l.f.cb.sd(Z:3158)
	at com.onseven.dbvis.l.f.c.b.b.n.f(Z:161)
	at com.onseven.dbvis.l.f.c.b.b.n.b(Z:1848)
	at com.onseven.dbvis.l.f.c.b.b.n.eb(Z:2399)
	at com.onseven.dbvis.l.f.c.b.m.q(Z:731)
	at com.onseven.dbvis.l.f.c.g.b(Z:1641)
	at com.onseven.dbvis.l.f.c.g.hb(Z:2642)
	at com.onseven.dbvis.l.f.c.g.qe(Z:2732)
	at com.onseven.dbvis.l.f.cb.ie(Z:236)
	at com.onseven.dbvis.l.f.m.c(Z:1374)
	at com.onseven.dbvis.l.f.m.doInBackground(Z:1521)
	at java.desktop/javax.swing.SwingWorker$1.call(SwingWorker.java:304)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.desktop/javax.swing.SwingWorker.run(SwingWorker.java:343)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:829)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.