Critical RCE Flaw Found in OpenVPN that Escaped Two Recent Security Audits
A security researcher has found four vulnerabilities, including a critical remote code execution bug, in OpenVPN, those were not even caught in the two big security audits of the open source VPN software this year.
OpenVPN is one of the most popular and widely used open source VPN software solutions mostly used for various connectivity needs, but it is especially popular for anonymous and private access to the Internet.
This year, two independent security audits of OpenVPN were carried out to look for flaws, backdoors, and other defects in the open source software – one conducted by a team led by Johns Hopkins University crypto-boffin Dr. Matthew D. Green.
The audits resulted in a patch of a few vulnerabilities in the widely used open source software, giving OpenVPN a clean chit.
Researcher Used Fuzzer to find Bugs in OpenVPN
Researcher Guido Vranken of Netherlands exclusively used a fuzzer and recently discovered four security holes in OpenVPN that escaped both the security audits.
Three of the four flaws the researcher discovered are server-side, two of which cause servers to crash, while the remaining is a client-side bug that could allow an attacker to steal a password to gain access to the proxy.
The most critical vulnerability of all is CVE-2017-7521, which affects OpenVPN server-side and resides in extract_x509_extension() function which deals with SSL certificates.
The vulnerability could allow a remote authenticated attacker to craft and send a certificate that either crashes the OpenVPN service or triggers a double free that potentially lead to remote code execution within the server.
Vranken was not able to demonstrate the RCE bug but argued that the remote code execution could be achieved in theory. In a report published Wednesday, he had explained how one could achieve a remote memory leak because of the service's failure to check a particular return value.
"If you look in the OpenSSL source code, one way through which ASN1_STRING_to_UTF8 can fail is if it cannot allocate sufficient memory," Vranken said in his report. "So the fact that an attacker can trigger a double-free IF the server has insufficient memory, combined with the fact that the attacker can arbitrarily drain the server of memory, makes it plausible that a remote double-free can be achieved."
"But if a double-free is inadequate to achieve remote code execution, there are probably other functions, whose behavior is wildly different under memory duress, that you can exploit."
The second vulnerability, CVE-2017-7520, resides in the way OpenVPN connects to a Windows NTLM version 2 proxy.
A man-in-the-middle attacker between the OpenVPN client and the proxy server can either remotely crash the client or steal the user's password to the proxy from a memory leak.
The vulnerability could be triggered only under certain circumstances, like when the client connects to a proxy through NTLM version 2 authentication, or when the client specifies a username ending with a backslash.
"If clients use a HTTP proxy with NTLM authentication (--http-proxy [|'auto'|'auto-nct'] ntlm2), a man-in-the-middle [MITM] attacker between the client and the proxy can cause the client to crash or disclose at most 96 bytes of stack memory," the OpenVPN team explains.
"The disclosed stack memory is likely to contain the proxy password. If the proxy password is not reused, this is unlikely to compromise the security of the OpenVPN tunnel itself. Clients who do not use the --http-proxy option with ntlm2 authentication are not affected."
Other two vulnerabilities (CVE-2017-7508 and CVE-2017-7522) are remote server crashes which could trigger by sending maliciously-crafted IPv6 packets or malicious data post-authentication.
Patches for Servers and Clients Already Available
Vranken responsibly disclosed all the vulnerabilities he discovered to the OpenVPN team in May and June and the team has already patched the issues in its latest version of the VPN software.
While there is no proof of any of the vulnerabilities had been publicly exploited, users are strongly advised to update their installations to OpenVPN versions 2.4.3 or 2.3.17 as soon as possible in order to be on the safer side.
For more in-depth technical details of all the vulnerabilities, you can head on to the report titled, _"The OpenVPN Post-Audit Bug Bonanza," _published by Vranken on Wednesday.