Governance & Risk Management , IT Risk Management , Patch Management
System Administrators Advised to Update to Latest Version That Addresses 2 Vulnerabilities Prajeet Nair (@prajeetspeaks) • March 26, 2021Users of the OpenSSL crypto library should upgrade immediately to the latest version to eliminate serious flaws that attackers could exploit to shut down servers, some security experts warn following the release of a security advisory by the OpenSSL Software Foundation.
See Also: The Cyberark Blueprint for Prvileged Access Management Success Rapid Risk Reduction Playbook
OpenSSL, one of the most commonly used software libraries, is a toolkit for the Transport Layer Security, or TLS, and Secure Sockets Layer, or SSL, protocols and a general-purpose cryptography library widely used to build networking applications and servers that require secure communications.
The upgrade addresses two vulnerabilities. CVE-2021-3449 is a denial-of-service flaw due to a NULL pointer dereference crash in default server configurations, which impacts the OpenSSL server and not the clients. CVE-2021-3450 is a certificate verification flaw that affects both the server and clients.
"CVE-2021-3450 ... was introduced by a change that rejects custom curve parameters (which is what broke Windows last year), and it only affects X509_V_FLAG_X509_STRICT mode," tweeted Filippo Valsorda, a cryptographic engineer. "CVE-2021-3449 looks like it could have been found easily if anyone figured out how to fuzz renegotiation, but renegotiation is sadness. Anyway, sounds like you can crash most OpenSSL servers on the internet today."
Fixing the two high-severity flaws with an upgrade to the latest version of OpenSSL is an essential risk mitigation step, says Tim Mackey, principal security strategist at the Synopsys Cybersecurity Research Center.
Denial of ServiceCVE-2021-3449 causes an OpenSSL TLS server to crash if it is sent a maliciously crafted renegotiation ClientHello message from a client, reports the advisory.
"If a TLSv1.2 renegotiation ClientHello omits the signature algorithms extension (where it was present in the initial ClientHello), but includes a signature_algorithms_cert extension, then a NULL pointer dereference will result, leading to a crash and a denial of service attack," the advisory notes.
A server is vulnerable to this attack if it has TLSv1.2 and renegotiation enabled - which is the default configuration. The OpenSSL Foundation says TLS clients are not impacted by this issue. But because all OpenSSL 1.1.1 versions are affected, the foundation recommends that users upgrade to OpenSSL 1.1.1k.
"In the case of CVE-2021-3449, an attacker could mount a denial of service attack against a default configuration of a server running any version of OpenSSL 1.1.1," Mackey notes.
"This issue was reported to OpenSSL on 17 March 2021 by Nokia, and the fix was developed by Peter Kästle and Samuel Sapalski from Nokia," the advisory states.
CA Certificate Check BypassCVE-2021-3450 involves the interplay between a X509_V_FLAG_X509_STRICT flag found in the code. This flag enables additional security checks of the certificates present in a certificate chain. The advisory notes that it is not set by default.
"For CVE-2021-3450, teams using the X509_V_FLAG_X509_STRICT flag to validate certificates should ensure that they've configured an acceptable "purpose" for the certificate chain, or when validating a TLS client or server certificate don't override the default purpose configuration. Since OpenSSL 1.1.0 has reached its end of support, the OpenSSL team didn't analyze it for any potential impact. OpenSSL users are advised to upgrade to version 1.1.1k," Mackey states.
This issue was reported to OpenSSL on March 18 by Benjamin Kaduk from Akamai and was discovered by Xiang Ding and others at Akamai the advisory states, adding that the fix was created by Tomáš Mráz, a software developer at the OpenSSL Software Foundation.
"Starting from OpenSSL version 1.1.1h, a check to disallow certificates in the chain that have explicitly encoded elliptic curve parameters was added as an additional check," the advisory notes. "An error in the implementation of this check meant that the result of a previous check to confirm that certificates in the chain are valid CA certificates was overwritten. This effectively bypasses the check that non-CA certificates must not be able to issue other certificates," the advisory notes.
To have certificates overridden or removed by an application due to this flaw, the application must set the X509_V_FLAG_X509_STRICT verification flag and either not set a purpose for the certificate verification or, in the case of TLS client or server applications, override the default purpose.
Posting Komentar
Posting Komentar