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 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.
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.
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.
Associated CVE ID | CVE-2023-0286 |
Description | A Type Confusion Vulnerability in OpenSSL that lets attackers to read private memory contents (such as private keys, or sensitive plaintext) and perform denial of service attacks. |
Associated ZDI ID | – |
CVSS Score | 7.5 High |
Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
Impact Score | – |
Exploitability Score | – |
Attack Vector (AV) | Network |
Attack Complexity (AC) | Low |
Privilege Required (PR) | None |
User Interaction (UI) | None |
Scope | Unchanged |
Confidentiality (C) | None |
Integrity (I) | None |
availability (a) | High |
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
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
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.
OpenSSL 3.0 users should upgrade to OpenSSL 3.0.8.
OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1t.
OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zg (premium support customers only).
Check the version of OpenSSL to see if you are vulnerable. Run this command to check the version of OpenSSL:
$ openssl version
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
Extract the downloaded package to a folder.
$ tar -zxf openssl-3.0.8.tar.gz
$ cd openssl-3.0.8/
Run this command to compile and create configdata.pm and makefile.
$ sudo ./config
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
$ sudo ln -s /usr/local/bin/openssl /usr/bin/openssl
Run these commands to update symbolic links and rebuild the library cache:
$ sudo ldconfig
Check the version of OpenSSL:
$ openssl version
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.
Edit ld.conf file to add a line containing /usr/local/lib64
$ 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:
How to Fix CVE-2022-0778- A Denial-Of-Service Vulnerability In OpenSSL
How to Fix CVE-2022-2274- A Heap Memory Corruption Vulnerability In OpenSSL
How To Fix Command Injection Vulnerabilities In OpenSSL In Just 5 Minutes
The Most Useful OpenSSL Commands to Work With SSL Certificates
How To Set Up A Certificate Authority On Ubuntu Using OpenSSL?
Arun KL is a cybersecurity professional with 15+ years of experience in IT infrastructure, cloud security, vulnerability management, Penetration Testing, security operations, and incident response. He is adept at designing and implementing robust security solutions to safeguard systems and data. Arun holds multiple industry certifications including CCNA, CCNA Security, RHCE, CEH, and AWS Security.
“Knowledge Arsenal: Empowering Your Security Journey through Continuous Learning”
"Cybersecurity All-in-One For Dummies" offers a comprehensive guide to securing personal and business digital assets from cyber threats, with actionable insights from industry experts.
BurpGPT is a cutting-edge Burp Suite extension that harnesses the power of OpenAI's language models to revolutionize web application security testing. With customizable prompts and advanced AI capabilities, BurpGPT enables security professionals to uncover bespoke vulnerabilities, streamline assessments, and stay ahead of evolving threats.
PentestGPT, developed by Gelei Deng and team, revolutionizes penetration testing by harnessing AI power. Leveraging OpenAI's GPT-4, it automates and streamlines the process, making it efficient and accessible. With advanced features and interactive guidance, PentestGPT empowers testers to identify vulnerabilities effectively, representing a significant leap in cybersecurity.
Tenable BurpGPT is a powerful Burp Suite extension that leverages OpenAI's advanced language models to analyze HTTP traffic and identify potential security risks. By automating vulnerability detection and providing AI-generated insights, BurpGPT dramatically reduces manual testing efforts for security researchers, developers, and pentesters.
Microsoft Security Copilot is a revolutionary AI-powered security solution that empowers cybersecurity professionals to identify and address potential breaches effectively. By harnessing advanced technologies like OpenAI's GPT-4 and Microsoft's extensive threat intelligence, Security Copilot streamlines threat detection and response, enabling defenders to operate at machine speed and scale.