opensearch-project / sql-jdbc Goto Github PK
View Code? Open in Web Editor NEWThis is the driver for JDBC connectivity to a cluster running with OpenSearch SQL support.
License: Apache License 2.0
This is the driver for JDBC connectivity to a cluster running with OpenSearch SQL support.
License: Apache License 2.0
What is the bug?
Correlation of all SQL related maintaners document
How can one reproduce the bug?
N/A
What is the expected behavior?
By in sync across all SQL repos
What is your host/environment?
All
Do you have any screenshots?
see
Do you have any additional context?
Add any other context about the problem.
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
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:
What is the expected behavior?
Tableau expects the message to be "Invalid username or password"
What is your host/environment?
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.
Describe the bug
In Dbvisualizer 23.1 cant see geo datatype data from opensearch connection
To Reproduce
SELECT
*
FROM
opensearch_dashboards_sample_data_flights;
Columns OriginLocation and DestLocation are null , all others are filled
Expected behavior
no errors all columns shown
Screenshots
Host/Environment (please complete the following information):
Additional context
Docker developer container - dev tools works fine..
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.
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
CVE | Severity | Dependency | Type | Fixed in (aws-java-sdk-core version) | Remediation Available | |
---|---|---|---|---|---|---|
CVE-2020-28491 | 7.5 | jackson-dataformat-cbor-2.6.7.jar | Transitive | 1.12.1 | ✅ |
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:
Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda
Found in base branch: main
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
Base Score Metrics:
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.
What is the bug?
JDBC version is hardcoded in multiple places.
How can one reproduce the bug?
Steps to reproduce the behavior:
What is the expected behavior?
One should use the other's version in order to avoid version mismatch occurrences.
What is your host/environment?
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
CVE | Severity | Dependency | Type | Fixed in (h2 version) | Remediation Available | |
---|---|---|---|---|---|---|
CVE-2022-45868 | 7.8 | h2-2.1.210.jar | Direct | N/A | ❌ |
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:
Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda
Found in base branch: main
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
Base Score Metrics:
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.
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.
Describe the bug
The JDBC driver is not returning SQLSTATE 28000 with invalid username or password authorization.
To Reproduce
Steps to reproduce the behavior:
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
JDBC
driver reports the precision of TIMESTAMP
columns as 24 - which is incorrect
ResultSetMetaData::getPrecision
https://docs.oracle.com/javase/8/docs/api/java/sql/ResultSetMetaData.html#getPrecision-int-
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).
JDBC: 1.1.0.1
Opened on behalf of @kylepbit
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:
org.opensearch.jdbc.Driver
auth
: AWS_SIGV4
region
: The region the cluster is onThis 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?
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
CVE | Severity | Dependency | Type | Fixed in (json-smart version) | Remediation Available | |
---|---|---|---|---|---|---|
CVE-2023-1370 | 7.5 | json-smart-2.4.8.jar | Direct | 2.4.9 | ✅ |
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:
Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda
Found in base branch: main
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
Base Score Metrics:
Type: Upgrade version
Release Date: 2023-03-22
Fix Resolution: 2.4.9
⛑️ Automatic Remediation is available for this issue
⛑️ Automatic Remediation is available for this issue.
What is the bug?
Retrieving time with a calendar always returns null.
How can one reproduce the bug?
Steps to reproduce the behavior:
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?
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.
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
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.
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]
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
select timestamp("1970-01-01 12:00:00.501");
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 |
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
2.x
@ e2bf2544
There are automated tests for JDBC driver with a real OpenSearch cluster
N/A
N/A
Add support for insert
and update
statements.
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:
What is the expected behavior?
The MAX_SIZE should be 10 instead of 24.
What is your host/environment?
getColumnTypeName
for timestamp depends whether cursor feature is active
Steps to reproduce the behavior:
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"}'
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");
typeName
is TIMESTAMP
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");
typeName
is DATE
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
}
main
N/A
Thanks @akuzin1 for reporting that
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
CVE | Severity | Dependency | Type | Fixed in (wiremock version) | Remediation Available | |
---|---|---|---|---|---|---|
CVE-2021-23369 | 9.8 | handlebars-4.0.7.jar | Transitive | N/A* | ❌ | |
CVE-2017-7657 | 9.8 | jetty-http-9.2.28.v20190418.jar | Transitive | N/A* | ❌ | |
CVE-2017-7656 | 7.5 | jetty-http-9.2.28.v20190418.jar | Transitive | N/A* | ❌ | |
CVE-2021-28165 | 7.5 | jetty-io-9.2.28.v20190418.jar | Transitive | N/A* | ❌ | |
CVE-2020-27216 | 7.0 | jetty-webapp-9.2.28.v20190418.jar | Transitive | N/A* | ❌ | |
CVE-2021-28169 | 5.3 | detected in multiple dependencies | Transitive | N/A* | ❌ | |
CVE-2021-29425 | 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.
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:
Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda
Found in base branch: main
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
Base Score Metrics:
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
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:
Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda
Found in base branch: main
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
Base Score Metrics:
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
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:
Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda
Found in base branch: main
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
Base Score Metrics:
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
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:
Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda
Found in base branch: main
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
Base Score Metrics:
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
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:
Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda
Found in base branch: main
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
Base Score Metrics:
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
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:
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:
Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda
Found in base branch: main
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
Base Score Metrics:
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
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:
Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda
Found in base branch: main
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
Base Score Metrics:
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
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?
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"
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
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
CVE | Severity | Dependency | Type | Fixed in (jetty-server version) | Remediation Available | |
---|---|---|---|---|---|---|
CVE-2017-7657 | 9.8 | jetty-server-9.2.28.v20190418.jar | Direct | 9.3.24.v20180605 | ✅ | |
CVE-2021-28169 | 5.3 | jetty-server-9.2.28.v20190418.jar | Direct | 9.4.41.v20210516 | ✅ | |
CVE-2021-34428 | 3.5 | jetty-server-9.2.28.v20190418.jar | Direct | 9.3.30.v20211001 | ✅ |
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:
Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda
Found in base branch: main
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
Base Score Metrics:
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
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:
Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda
Found in base branch: main
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
Base Score Metrics:
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
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:
Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda
Found in base branch: main
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
Base Score Metrics:
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.
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)
// 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());
}
}
}
Driver should be able to generate java.time
classes.
2.x
@ e2bf2544
N/A
N/A
Is your feature request related to a problem?
At ApacheCon 2022, we spoke with folks from DBeaver, who noted that their customers wanted integration with OpenSearch (dbeaver/dbeaver#17811). DBeaver depends on JDBC drivers, and their preferred method of consuming the package is from Maven.
What solution would you like?
Publish the JDBC driver to Maven.
Follow opensearch-project/.github#125 to baseline MAINTAINERS, CODEOWNERS, and external collaborator permissions.
Close this issue when:
If this repo's permissions was already baselined, please confirm the above when closing this issue.
Driver handles incorrectly empty paging responses
Driver stops paging the cursor if response is empty. Criteria to stop paging is no cursor returned.
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.
Driver should scroll the cursor until received response has no cursor.
1.2.0.0 from maven
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:
How can one reproduce the bug?
Steps to reproduce the behavior:
resultSet.getObject(<fieldName>)
or resultSet.getObject(<fieldName>, <xxx.class>)
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?
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
CVE | Severity | Dependency | Type | Fixed in (jackson-databind version) | Remediation Available | |
---|---|---|---|---|---|---|
CVE-2022-42004 | 7.5 | jackson-databind-2.13.3.jar | Direct | 2.13.4 | ✅ | |
CVE-2022-42003 | 7.5 | jackson-databind-2.13.3.jar | Direct | 2.13.4.1 | ✅ |
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:
Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda
Found in base branch: main
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
Base Score Metrics:
Type: Upgrade version
Release Date: 2022-10-02
Fix Resolution: 2.13.4
⛑️ Automatic Remediation is available for this issue
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:
Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda
Found in base branch: main
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
Base Score Metrics:
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.
What is the bug?
Manifest file in the tableau connector does not indicate that booleans are supported natively.
What is the expected behavior?
It should be supported in the manifest as OpenSearch supports booleans natively.
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
CVE | Severity | Dependency | Type | Fixed in (jetty-server version) | Remediation Available | |
---|---|---|---|---|---|---|
CVE-2023-26048 | 5.3 | jetty-server-11.0.12.jar | Direct | 11.0.14 | ✅ |
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:
Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda
Found in base branch: main
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
Base Score Metrics:
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.
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:
SELECT * FROM opensearch_dashboards_sample_data_flights
Expected behavior
Expect JDBC driver can handle properly and display geo point field values well as others.
Screenshots
Host/Environment (please complete the following information):
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)
It'd be great if users could access the OpenSearch Tableau connector directly from the Tableau application and listed on Tableau Exchange.
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
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?
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.
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.
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
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
CVE | Severity | Dependency | Type | Fixed in (httpclient version) | Remediation Available | |
---|---|---|---|---|---|---|
WS-2019-0379 | 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.
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:
Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda
Found in base branch: main
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
Base Score Metrics:
Type: Upgrade version
Release Date: 2019-05-20
Fix Resolution: commons-codec:commons-codec:1.13
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
CVE | Severity | Dependency | Type | Fixed in (wiremock version) | Remediation Possible** | |
---|---|---|---|---|---|---|
WS-2023-0236 | 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
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:
Found in HEAD commit: 885b414d657c387125332f71c57c0f24afcbabda
Found in base branch: main
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
Base Score Metrics:
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
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
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.
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?
Do you have any additional context?
When JDBC executes a statement, it sets fetch_size
parameter to 100. This fails this check here.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.