Two high-severity vulnerabilities were recently revealed to be present in the popular cryptography library, OpenSSL. While one of the vulnerabilities can allow an attacker to bypass CA Certificate checks, the other could lead to a Denial of Service (DoS) condition.
OpenSSL is a well-known open-source cryptography library that facilitates the implementation of the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. It is used to secure communication over computer networks.
CVE-2021-3449: NULL pointer dereference in signature_algorithms processing
The flaw arises as a result of the renegotiation feature of TLS. Renegotiation involves initiating a new handshake over an existing SSL/TLS connection with different security parameters. A TLS client attempts renegotiation by sending a ClientHello message to the TLS Server. A typical negotiation usually consists of the signature_algorithms extension, which specifies the signature algorithms that the client can accept. However, an attacker could make the TLS client transmit the ClientHello message, excluding the signature_algorithms extension. Since the extension was present in the initial negotiation message, the server fails to recognize the exclusion. This results in a NULL pointer dereference as the server attempts to access an inexistent memory location, leading to a denial of service attack.
Note that TLS clients are not affected by this vulnerability, and it only impacts servers with TLS1.2 and renegotiation enabled.
CVE-2021-3450: CA certificate check bypass with X509_V_FLAG_X509_STRICT
This bug resides in the implementation of X509_V_FLAG_X509_STRICT, a flag utilized by the OpenSSL client. It is used to implement additional security checks while setting up a new TLS connection and is disabled by default.
A Certification Authority (CA) is a trusted issuer of digital certificates. Digital certificates bind the identity of the owner of the certificate to a public key. The application that sets up the TLS connection first checks whether the certificate is signed by a CA and then checks if that CA is among a list of trusted authorities. Once these verifications are done, the TLS connection is deemed as verified.
OpenSSL uses the Elliptic Curve Cryptography (ECC) algorithm for encryption and decryption. While the actual mathematics used in ECC algorithms may be very complicated, we can consider the standard equation of an ellipse:
x2/a2 + y2/b2 = 1
Here a and b are crucial parameters for calculating the height and width of the resulting ellipse. These parameters, if disproportionate in comparison to each other, would result in an abstruse ellipse. Similarly, attackers would intentionally implement adverse parameters to impact the strength of the encryption. Hence, a set of standard ECC parameters were established in a bid to prevent the above issue.
Coming back to the vulnerability, the X509_V_FLAG_X509_STRICT check ensures that the certificates using non-standard elliptic curve parameters are not allowed. However, the implementation of this check resulted in a security flaw. Simply put, if an attacker were to pass on a crafted certificate that is not verified by a CA, this certificate would be disapproved. However, if the same certificate makes use of standard ECC parameters and X509_V_FLAG_X509_STRICT is enabled, the previous result would be overridden. This would result in the certificate being declared as verified, thus rendering the security checks useless.
Note that X509_V_FLAG_X509_STRICT was introduced with OpenSSL version 1.1.1h.
The vendor advisory is available here.
One of the flaws could allow attackers to bypass CA certificate checks, resulting in spoofing attacks and information disclosure. The second flaw could facilitate denial of service attacks.
CVE-2021-3449 impacts all versions of OpenSSL 1.1.1 before 1.1.1k.
CVE-2021-3450 impacts versions 1.1.1h before 1.1.1k.
OpenSSL has released the security updates addressing the issue in OpenSSL version 1.1.1k.