A proof-of-concept (PoC) exploit has been made public for a recently patched vulnerability in OpenSSL that can be exploited for denial-of-service (DoS) attacks.
OpenSSL versions 1.1.1d, 1.1.1e and 1.1.1f are affected by a high-severity vulnerability that has been described as a segmentation fault in the SSl_check_chain function. The flaw, tracked as CVE-2020-1967, was patched on April 21 with the release of OpenSSL 1.1.1g.
The security hole was discovered by Bernd Edlinger using a recently introduced GNU Compiler Collection (GCC) static code analyzer.
Security researcher Imre Rad has published a PoC exploit for the vulnerability, along with a description of the exploitation process.
“Exploitation of this vulnerability is pretty easy, one just needs to send the malicious payload to the vulnerable server — this can be done for example by using the patched openssl s_client utility available on my GitHub page,” Rad told SecurityWeek.
He added, “The victim’s side is more complex — the application is vulnerable only if using the affected version of the lib and calling the SSL_check_chain() public API function. This is not really common — I’d even dare to say the vast majority of TLS servers don’t call that function. But the ones that do — the severity of this threat is indeed high for them.”
“I’ve seen some vendors confirming they are affected — not sure though whether they did a simple version checking or verified the function call as well. The affected server crashes upon receiving the payload — depending on whether a watchdog is supervising the process or not, it may go temporarily or permanently down,” Rad said. “Also worth to mention, services using mutual TLS for authentication are not protected either — the vulnerable code resides in the TLS 1.3 handshake processing.”
The researcher said the vulnerability can also be exploited through a man-in-the-middle (MitM) attack or by setting up a malicious TLS server and getting a vulnerable client to connect to it.
“The impact of taking a client down is usually considered lower, so I didn’t analyze this any further, but I see nothing that could prevent exploitation of it (given that using the vulnerable version of the lib and calling that function),” Rad noted.
The researcher said he was hesitant to make the PoC exploit public due to concerns that it could be abused.
“I don’t want to be blamed for what script kiddies do — but then I recalled Schneier’s views about full disclosure and I had to admit that is the way to go forward (others could develop a similar exploit easily anyway),” Rad said via email.
CVE-2020-1967 was the first vulnerability patched in OpenSSL in 2020. As SecurityWeek reported a few months ago, OpenSSL security has evolved since the disclosure of the Heartbleed vulnerability back in 2014.
While nearly a dozen critical and high-severity vulnerabilities were found in OpenSSL between the disclosure of Heartbleed and the end of 2016, in 2017 there was only one high-severity flaw identified, and in 2018 and 2019 all the patched issues had low or medium severity.
Related: Evolution of OpenSSL Security After Heartbleed
Related: OpenSSL 1.1.1 Released With TLS 1.3, Security Improvements
