OpenSSL Fixes High-Severity Flaw That Allowed DoS
OpenSSL, the most widely used software library for implementing website and email encryption, has patched a high-severity vulnerability that makes it easy for hackers to completely shut down huge numbers of servers.
OpenSSL provides time-tested cryptographic functions that implement the Transport Layer Security protocol, the successor to Secure Sockets Layer that encrypts data flowing between Internet servers and end-user clients. People developing applications that use TLS rely on OpenSSL to save time and avoid programming errors that are common when noncryptographers build applications that use complex encryption.
The crucial role OpenSSL plays in Internet security came into full view in 2014 when hackers began exploiting a critical vulnerability in the open source code library that let them steal encryption keys, customer information, and other sensitive data from servers all over the world. Heartbleed, as the security flaw was called, demonstrated how a couple lines of faulty code could topple the security of banks, news sites, law firms, and more.
Denial-of-service bug squashed
On Thursday, OpenSSL maintainers disclosed and patched a vulnerability that causes servers to crash when they receive a maliciously crafted request from an unauthenticated end user. CVE-2021-3449, as the denial-of-server vulnerability is tracked, is the result of a null pointer dereference bug. Cryptographic engineer Filippo Valsorda said on Twitter that the flaw could probably have been discovered earlier than now.
“Anyway, sounds like you can crash most OpenSSL servers on the Internet today,” he added.
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.
— Filippo Valsorda ??❤️ ✊ (@FiloSottile) March 25, 2021
Hackers can exploit the vulnerability by sending a server a maliciously formed renegotiating request during the initial handshake that establishes a secure connection between an end user and a server.
“An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client,” maintainers wrote in an 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 maintainers have rated the severity high. Researchers reported the vulnerability to OpenSSL on March 17. Nokia developers Peter Kästle and Samuel Sapalski provided the fix.
Certificate verification bypass
OpenSSL also fixed a separate vulnerability that, in edge cases, prevented apps from detecting and rejecting TLS certificates that aren’t digitally signed by a browser-trusted certificate authority. The vulnerability, tracked as CVE-2021-3450, involves the interplay between a X509_V_FLAG_X509_STRICT flag found in the code and several parameters.
Thursday’s advisory explained:
If a “purpose” has been configured then there is a subsequent opportunity for checks that the certificate is a valid CA. All of the named “purpose” values implemented in libcrypto perform this check. Therefore, where a purpose is set the certificate chain will still be rejected even when the strict flag has been used. A purpose is set by default in libssl client and server certificate verification routines, but it can be overridden or removed by an application.
In order to be affected, an application must explicitly 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.
OpenSSL versions 1.1.1h and newer are vulnerable. OpenSSL 1.0.2 is not impacted by this issue. Akamai researchers Xiang Ding and Benjamin Kaduk discovered and reported the bug, respectively. It was patched by Tomáš Mráz, a software developer who contracts with OpenSSL Software Services.
Apps that use a vulnerable OpenSSL version should upgrade to OpenSSL 1.1.1k as soon as possible.
READ MORE HERE