OpenVPN has this week patched four vulnerabilities, including a critical remote code execution bug, a little more than a month after the results of two security audits of the open source VPN software were published.
The patches were released after private disclosures in May and June by researcher Guido Vranken of the Netherlands. Vranken said the vulnerabilities were not turned up in either audit, which were a combination of manual source code reviews and automated scanning; Vranken said he exclusively used a fuzzer to find these bugs.
The most critical vulnerability, CVE-2017-7521, affects OpenVPN server side and could allow an authenticated hacker to run code on a compromised box.
“CVE-2017-7521 can drain the server of available memory, which may lead to a ‘double-free,’ which is a way to corrupt the server’s memory. In short, the worst-case scenario is that the user can execute their code on the server,” Vranken said. “This is the worst vulnerability. They authenticate and then send crafted data, after which the server crashes. I’d say this a worrisome issue for (commercial) VPN providers, so they definitely need to update as soon as possible.”
Vranken was unaware whether any of the vulnerabilities had been publicly exploited.
“This is difficult for me to say. But I’d say that if I can do this in a couple of weeks of spare time out of sheer curiosity, heavily funded organizations with political objectives can do it too,” he said.
Three of the four vulnerabilities Vranken discovered were server-side with the other two causing servers to crash. The client-side bug allows an attacker to steal a password to gain access to the proxy, Vranken said, adding that the three server flaws require the attacker be authenticated in order to exploit.
“The crashes and the one that steals the password are not so difficult. A medium level of understanding of the C programming language and computer internals would be sufficient,” Vranken said as to the ease of exploit. “It is also relatively easy to drain the server of memory. But to exploit that to achieve remote code execution, requires a high level of expertise.”
Vranken provide in-depth technical explanations of each bug in a report published today. In the critical vulnerability, Vranken explains how he achieved a remote memory leak because of OpenVPN’s failure to check a particular return value. From his report:
“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. 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 client-side bug also merits attention, Vranken said, adding that it is triggered only under particular certain circumstances, such as when the client connects to a proxy via NTLM version 2 authentication.
“All the server issues require that the user is authenticated. This requires that the system administrator signs the certificate of a malicious user,” Vranken said. “For individual users who run their private server this is unlikely to occur, but it is bad for VPN services that have automated this process for a large group of (untrusted) users.”
One of the OpenVPN audits, carried out from December 2016 to February 2017, found a handful of low and medium issues but no major vulnerabilities. That audit lauded OpenVPN’s overall cryptographic design, calling it solid with a caveat that some implementations could “undermine a user’s ability to deploy a secure VPN solution” however. These bugs were patched in May.
The other audit was more of a security evaluation of the software running in OpenVPN 2.4.0; it found two bugs that were also patched in May.
