cancel
Showing results for 
Search instead for 
Did you mean: 
Data Engineering
Join discussions on data engineering best practices, architectures, and optimization strategies within the Databricks Community. Exchange insights and solutions with fellow data engineers.
cancel
Showing results for 
Search instead for 
Did you mean: 

CVE-2022-0778

Vikram
New Contributor II

How can we update the OpenSSL version for the cluster to address this vulnerability ?

https://ubuntu.com/security/CVE-2022-0778

Tried with this global init script to auto update the openssl version but does not seem to work as apt-utils is missing.

apt-get update

apt-get install --only-upgrade openssl

I have tried modifying the global init script as follows to fix the missing apt-utils.

apt-get update

apt-get install -y --no-install-recommends apt-utils

apt-get install --only-upgrade openssl

Please suggest the right way to fix this vulnerability. BTW i have used 10.4 LTS available in Azure databricks as the runtime.

1 ACCEPTED SOLUTION

Accepted Solutions

Atanu
Esteemed Contributor

I can see below from our internal communication.

CVSSv3 score: 4.0 (Medium) AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:L

Reference: https://www.openssl.org/news/secadv/20220315.txt

Severity: High

The BN_mod_sqrt() function, which computes a modular square root, contains a bug that can cause it to loop forever for non-prime moduli.

Internally this function is used when parsing certificates that contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a base point encoded in compressed form.

It is possible to trigger the infinite loop by crafting a certificate that has invalid explicit curve parameters.

Since certificate parsing happens prior to verification of the certificate signature, any process that parses an externally supplied certificate may thus be subject to a denial of service attack. The infinite loop can also be reached when parsing crafted private keys as they can contain explicit elliptic curve parameters.

Thus vulnerable situations include:

  • TLS clients consuming server certificates
  • TLS servers consuming client certificates
  • Hosting providers taking certificates or private keys from customers
  • Certificate authorities parsing certification requests from subscribers
  • Anything else which parses ASN.1 elliptic curve parameters

Also any other applications that use the BN_mod_sqrt() where the attacker can control the parameter values are vulnerable to this DoS issue.

In the OpenSSL 1.0.2 version the public key is not parsed during initial parsing of the certificate which makes it slightly harder to trigger the infinite loop. However any operation which requires the public key from the certificate will trigger the infinite loop. In particular the attacker can use a self-signed certificate to trigger the loop during verification of the certificate signature.

This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. It was addressed in the releases of 1.1.1n and 3.0.2 on the 15th March 2022.

OpenSSL 1.0.2 users should upgrade to 1.0.2zd (premium support customers only)

OpenSSL 1.1.1 users should upgrade to 1.1.1n

OpenSSL 3.0 users should upgrade to 3.0.2

This issue was reported to OpenSSL on the 24th February 2022 by Tavis Ormandy from Google. The fix was developed by David Benjamin from Google and Tomáš Mráz from OpenSSL.

View solution in original post

4 REPLIES 4

Hubert-Dudek
Esteemed Contributor III

I see that runtime 10.4 includes OpenSSL 1.4.6 (source https://docs.databricks.com/release-notes/runtime/10.4.html ) and regarding security issue it affects OpenSSL versions 1.0.2, 1.1.1 and 3.0.

Vikram
New Contributor II

I believe you are referring to the OpenSSL bindings on R as version 1.4.6

https://cran.r-project.org/web/packages/openssl/index.html

That is different from the openssl installed on the machine through apt linux distribution. If you type the following command in bash, you should see the underlying openssl version.

openssl version -a

OpenSSL 1.1.1f 31 Mar 2020

I am still waiting for answer to this question.

Atanu
Esteemed Contributor

I can see below from our internal communication.

CVSSv3 score: 4.0 (Medium) AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:L

Reference: https://www.openssl.org/news/secadv/20220315.txt

Severity: High

The BN_mod_sqrt() function, which computes a modular square root, contains a bug that can cause it to loop forever for non-prime moduli.

Internally this function is used when parsing certificates that contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a base point encoded in compressed form.

It is possible to trigger the infinite loop by crafting a certificate that has invalid explicit curve parameters.

Since certificate parsing happens prior to verification of the certificate signature, any process that parses an externally supplied certificate may thus be subject to a denial of service attack. The infinite loop can also be reached when parsing crafted private keys as they can contain explicit elliptic curve parameters.

Thus vulnerable situations include:

  • TLS clients consuming server certificates
  • TLS servers consuming client certificates
  • Hosting providers taking certificates or private keys from customers
  • Certificate authorities parsing certification requests from subscribers
  • Anything else which parses ASN.1 elliptic curve parameters

Also any other applications that use the BN_mod_sqrt() where the attacker can control the parameter values are vulnerable to this DoS issue.

In the OpenSSL 1.0.2 version the public key is not parsed during initial parsing of the certificate which makes it slightly harder to trigger the infinite loop. However any operation which requires the public key from the certificate will trigger the infinite loop. In particular the attacker can use a self-signed certificate to trigger the loop during verification of the certificate signature.

This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. It was addressed in the releases of 1.1.1n and 3.0.2 on the 15th March 2022.

OpenSSL 1.0.2 users should upgrade to 1.0.2zd (premium support customers only)

OpenSSL 1.1.1 users should upgrade to 1.1.1n

OpenSSL 3.0 users should upgrade to 3.0.2

This issue was reported to OpenSSL on the 24th February 2022 by Tavis Ormandy from Google. The fix was developed by David Benjamin from Google and Tomáš Mráz from OpenSSL.

Hi @Vikram Pentakota​ ,

Just a friendly follow-up. Did @Atanu Sarkar​ 's response help you to resolved your question? if yes, please mark it as best response.

Connect with Databricks Users in Your Area

Join a Regional User Group to connect with local Databricks users. Events will be happening in your city, and you won’t want to miss the chance to attend and share knowledge.

If there isn’t a group near you, start one and help create a community that brings people together.

Request a New Group