OpenSSL Addresses Two High Severity Vulnerabilities. Patch Now!

On October 25, 2022, the OpenSSL team issued a major flaw alert to users. OpenSSL 3.0.7 was released on November 1, 2022, to fix two serious vulnerabilities, CVE-2022-3786 and CVE-2022-3602. These flaws initially given a critical rating before being lowered to high. OpenSSL is a widely used cryptographic library that protects conversations over computer networks against eavesdropping. It is to produce CSRs, install SSL/TLS certificates, execute encryption and decryption, and get private keys. OpenSSL Addresses High Severity Vulnerabilities 2022. This can be addressed using the right vulnerability management tool.

The X.509 certificate verification process leveraged to exploit these flaws (buffer overrun), which allows an attacker to cause a denial of service or execute the remote code. These vulnerabilities are not only limited to OpenSSL binary; the OpenSSL library is utilized by many software, operating systems, etc., which makes it critical to patch all vulnerable software using the vulnerable library at the earliest. Hence, it is essential to have a reliable patch management tool.

CVE-2022-3786: A buffer overrun can occur in X.509 certificate verification, notably in name constraint checks. This happens post certificate chain signature verification, and it requires either a malicious certificate signed by a CA or an application to continue to do certificate verification despite being unable to create a path to a trustworthy issuer. In a certificate, the fraud email address can be by an attacker to cause the stack to overflow with any number of bytes that contain the character “.”. which allows an attacker to cause a denial of service condition when a TLS client connects to a rogue server. This could occur on a TLS server if a fraud client joins when the server is asking for client authentication.

CVE-2022-3602: A buffer overrun can occur in X.509 certificate verification, notably in name constraint checks. This happens post certificate chain signature verification, and requires either a malicious certificate signed by a CA or an application to continue to do certificate verification despite being unable to create a path to a trustworthy issuer. To fill up four attacker-controlled bytes on the stack, an attacker can create a fraud email address. This buffer overflow could result in a denial of service condition or remote code execution. This can occur in a TLS client by connecting to a rogue server. This could occur on a TLS server if a fraud client joins when the server is asking for client authentication.

According to the technical details mentioned above, the attack scenario that is possible are:

• When a server is the intended victim, the server must first ask the client for authentication as part of a mutual authentication configuration. This setup is unique and typically only used in high-security environments.
• When a client is the intended victim, the attacker must first force a vulnerable client into connecting to a malicious server. The attacker must use social engineering skills to make a person click on the fraud link using phishing or a Man-In-The-Middle Attack.

OpenSSL servers and clients are susceptible to this attack; however, a client exploiting a server is more likely than a server exploiting a client. Servers set up for bi-directional authentication, where both sides of the connection exchange and check certificates, it is possible for a client to take advantage of a server by transmitting a malicious or corrupt certificate.

When validating X.509 certificates, OpenSSL is vulnerable because Punycode processes incorrectly. Punycode is a limited ASCII character subset encoding of Unicode strings. It is typically to encrypt domain names that contain characters other than ASCII. “xn—” is the first character in a punycode– string, followed by English characters and digits. During Punycode string decoding, the ossl_punycode_decode() function vulnerability may result in a buffer overrun. It triggers when OpenSSL processes a certificate chain.

Now, how can we exploit this vulnerability:

• Create a malicious Punycode string in the “nameConstraints” field of a CA or Intermediary certificate. In addition to “xn—,” the Punycode string must include at least 512 bytes.
• Create a leaf certificate with a SubjectAlternateName otherName field that contains the string SmtpUTF8Mailbox.

This is how you can get which OpenSSL version you are running and check whether your setup is vulnerable to the affected version section. This is how OpenSSL Addresses High Severity Vulnerabilities 2022.

To detect and patch this vulnerability automatically, you can use our product SanerNow.

OpenSSL Versions 3.0.0 to 3.0.6.

Successful exploitation will allow the attacker to create a denial of service condition or execute the remote code.

OpenSSL 3.0.7.

SanerNow VM and SanerNow PM detect these vulnerabilities and remediate them, respectively. We strongly recommend applying the security update following the instructions posted in our support article.