OpenVPN taken to task after audit ignores remote code execution flaws

Serious security bugs have been exposed, some of which can lead to remote code execution.

hackingx1filephoto.png
File Photo

A researcher has revealed four dangerous bugs, among others, in OpenVPN which two recent audits of the virtual private network's code failed to find.

According to security expert Guido Vranken, he independently used a fuzzer to cut through OpenVPN's code to find the bugs.

The first vulnerability, CVE-2017-7521, is a set of issues found in the extract_x509_extension, in which attackers can create a remote server crash and memory leaks.

If the user has utilized the x509-username-field configuration, a storage issue results in crashes, loops can be caused by a failure to check strings and return values properly, and a naming issue causes memory leak problems.

"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, making it plausible that a remote double-free can be achieved," the researcher says. "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, only affects users who use OpenVPN to connect to a Windows NTLM version 2 proxy.

A man-in-the-middle (MiTM) attack is possible, resulting in data leaks and potential surveillance -- and as user passwords are stored in cleartext, this may also compromise the user further.

In addition, a code issue with signed variables can cause memory and remote crashes.

Another bug Vranken discovered while fuzzing is a remote client stack buffer corruption bug. While the researcher calls it "exceedingly unlikely to occur," a MiTM attack again used in conjunction with a NTLM version 2 proxy can result in the compromise of the my_strupr function in ntlm.c.

An additional security flaw, CVE-2017-7508, can be used to crash the OpenVPN server. If an attacker sends crafted data to the system, it is possible to send a malicious data packet which prevents certain code assertions from operating correctly, forcing the server to stop.

Vranken also reported CVE-2017-7522 to OpenVPN, a vulnerability leading to crashes of TLS/PolarSSL-based servers, which affects OpenVPN 2.4 if compiled with mbed TLS/PolarSSL.

When parsing certificates, due to static strings being stored in read-only memory, this can cause servers to crash.

Finally, another bug -- with no CVE assignment -- can cause stack buffer overflow corruption if a long -tls-cipher option is implemented.

However, as this only impacts users who load untrusted options, this is not considered a true security risk as untrusted configuration options can also lead to remote code execution by design.

"Most of these issues were found through fuzzing," Vranken said. "I hate admitting it, but [..] the arcane art of reviewing code manually, acquired through grueling practice, are dwarfed by the fuzzer in one fell swoop; the mortal's mind can only retain and comprehend so much information at a time, and for programs that perform long cycles of complex, deeply nested operations it is simply not feasible to expect a human to perform an encompassing and reliable verification."

OpenVPN's audits, carried out over the past two years, missed these major flaws. While a handful of other bugs are found, perhaps OpenVPN should consider adding fuzzing to their internal security analysis in the future.

Considering VPNs are used by those concerned about their privacy and security online, any bug which leaves this kind of software vulnerable is bad news. Users should accept automatic updates, now released to patch these issues among others, to stay safe.