How to Fix CVE-2023-0286- A Type Confusion Vulnerability in OpenSSL?

On 7th Feb, OpenSSL published an advisory that talks about a high-severity vulnerability in its software library. The flaw that is tracked as CVE-2023-0286 is a type confusion vulnerability relating to X.400 address processing inside an X.509 GeneralName. Since the flaw allows attackers to read private memory contents (such as private keys or sensitive plaintext) and perform a denial of service attack, it is important to learn how to Fix CVE-2023-0286- A high-severity Type Confusion Vulnerability in OpenSSL.

Before we jump in to learn how to Fix CVE-2023-0286- A high severity Type Confusion Vulnerability in OpenSSL, let’s see about the OpenSSL, X.400 address, X.509 GeneralName, and CRL (Certificate Revocation List) in public key infrastructure ecosystem.

OpenSSL

OpenSSL is a widely-used open-source implementation of the SSL and TLS protocols. It includes a library of cryptographic algorithms, which can be used to encrypt data. RSA is one of the algorithms that is supported by OpenSSL.

X.400 address and X.509 GeneralName

In public key infrastructure, X.400 is standard for an electronic mail addressing format that is used to send messages over computer networks. An X.400 address is essentially a mailing address. It is used in certificate processing and helps to identify entities involved in secure communication. On the other hand, X.509 is a standard for a public key infrastructure (PKI) that provides a basis for authentication and authorization over the internet. X.509 GeneralName holds X.400 addresses. The X.509 GeneralName, along with other data, makes up a certificate, which is used to verify the identity of an entity involved in a secure communication.

Summary of CVE-2023-0286

This is a high-severity type confusion vulnerability in OpenSSL. The flaw is something related to the way X.400 addresses are being parsed. OpenSSL library is supposed to parse the X.400 address as a ASN1_STRING data type, but it is being parsed as ASN1_TYPE data type, which is incorrect. This resulted in an archetypical type confusion vulnerability.

This flaw is identified when the certificate revocation list (CRL) validation process is being performed. The CRL (Certificate Revocation List) validation process is used to verify that certificates issued by Certificate Authorities are still valid. It is an essential security measure designed to validate CRLs regularly to ensure the integrity and security of their system. 

The CRL validation process begins with a certificate authority (CA) issuing a CRL that contains a list of revoked certificates. As part of the validation process, OpenSSL will need to compare two X.400 addresses. OpenSSL does this comparison using the memcmp C function. Due to the vulnerability, X.400 addresses were stored in ASN1_TYPE data type instead of ASN1_STRING structs data type. 

Due to the difference in memory layout between the ASN1_TYPE and ASN1_STRING structs, it is possible for attackers to specify an arbitrary memory address to be supplied to memcmp. This then leads to comparisons against memory specified by the attacker, potentially allowing for the disclosure of memory contents and denial of service.

In most cases, the attack requires the attacker to provide both the certificate chain and CRL, neither of which need to have a valid signature. If the attacker only controls one of these inputs, the other input must already contain an X.400 address as a CRL distribution point, which is uncommon. As such, this vulnerability is most likely to only affect applications which have implemented their own functionality for retrieving CRLs over a network.
In most cases, the attack requires the attacker to provide both the certificate chain and CRL, neither of which need to have a valid signature. If the attacker only controls one of these inputs, the other input must already contain an X.400 address as a CRL distribution point, which is uncommon. As such, this vulnerability is most likely to only affect applications which have implemented their own functionality for retrieving CRLs over a network.– David Benjamin from Google

OpenSSL Versions Vulnerable To CVE-2023-0286

The official advisory says OpenSSL versions 3.0, 1.1.1, and 1.0.2 are vulnerable to this vulnerability. We suggest checking the OpenSSL versions running on your servers and taking action to fix CVE-2023-0286, a high-severity Type Confusion Vulnerability in OpenSSL.

Run this command to check the version of the OpenSSL running on your machine.

$ openssl version

How to Fix CVE-2023-0286- A Type Confusion Vulnerability in OpenSSL?

OpenSSL addresses the vulnerabilities in its new releases. OpenSSL has rolled out a new version with the patch. We suggest finding out the current version of OpenSSL on your machines and upgrading to v3.0.8, 1.1.1t, and 1.0.2zg.

How to Fix CVE-2023-0286

Step 1. Determine if You are Vulnerable

Check the version of OpenSSL to see if you are vulnerable. Run this command to check the version of OpenSSL:

$ openssl version

Step 2. Download the latest OpenSSL package

Download the correct package you need. In this case, since we have OpenSSL v3.0.2, we need to download v3.0.8, 1.1.1t, or 1.0.2zg.


$ cd Downloads/

$ wget https://www.openssl.org/source/openssl-3.0.8.tar.gz

$ chmod +x openssl-3.0.5.tar.gz

Step 3. Extract the OpenSSL package

Extract the downloaded package to a folder.

$ tar -zxf openssl-3.0.8.tar.gz

$ cd openssl-3.0.8/

Step 4. Compile OpenSSL 3.0.8 Source Code

Run this command to compile and create configdata.pm and makefile.

$ sudo ./config

Step 5. Install/upgrade OpenSSL

Issue these commands to install or upgrade the OpenSSL.


$ sudo make
$ sudo make test
$ sudo mv /usr/bin/openssl ~/tmp (Backup current openssl binary)
$ sudo make install
$ sudo ldconfig /usr/local/lib64/

Note: You may need to install make and gcc utilities before you install or upgrade the OpenSSL. Run this command to install the required packages if not preinstalled.

$ sudo apt install make gcc

Step 6. Create symbolic link from newly install binary to the default location

$ sudo ln -s /usr/local/bin/openssl /usr/bin/openssl

Step 7. Update the symbolic links in Ubuntu

Run these commands to update symbolic links and rebuild the library cache:

$ sudo ldconfig

Step 8. Check the OpenSSL version once again after the patch

Check the version of OpenSSL:

$ openssl version

How To Fix The OpenSSL Error Loading Shared Libraries?

Some people would get an error in loading shared libraries. If you are one among those with such bad luck, if you see this error “openssl: error while loading shared libraries: libssl.so.3: cannot open shared object file: No such file or directory“, then this section is for you.

$ sudo nano /etc/ld.so.conf.d/lib.conf
/usr/local/lib64

OR

2. Sometimes, openssl is installed at /usr/local/ssl. Create a file and add a line containing /usr/local/ssl/lib64

$ sudo nano /etc/ld.so.conf.d/openssl.conf
/usr/local/ssl/lib64

Update the library paths upon adding the path to the file.

$ sudo ldconfig

Check the OpenSSL version.

$ openssl version
OpenSSL 3.0.8 7 Feb 2023 (Library: OpenSSL 3.0.8 7 Feb 2023)

We hope this post would help you know how to Fix CVE-2023-0286- A high-severity Type Confusion Vulnerability in OpenSSL. Please share this post and help to secure the digital world. Visit our social media page on Facebook, LinkedIn, Twitter, Telegram, Tumblr, Medium & Instagram, and subscribe to receive updates like this. 

You may also like these articles: