Researcher calls the fuzz on OpenVPN, uncovers crashy vulns
Patches for servers and clients already out there – get updating just in case
OpenVPN has patched a bunch of security vulnerabilities that can be exploited to crash the service or, at a pinch, potentially gain remote-code execution.
You should update your installations to versions 2.4.3 or 2.3.17 as soon as you can just to be on the safe side.
The four holes were found by Guido Vranken, who took a fuzzer to the widely used VPN software, and worked independently of the OpenVPN team's big code audit this year. He published his findings on Wednesday.
First in the list is CVE-2017-7521, a cockup in
extract_x509_extension() function which deals with SSL certificates. It is possible for a remote authenticated user to craft and send over a certificate that either crashes an OpenVPN service, or triggers a double-free() to potentially gain remote code execution within the server.
Vranken was unable to demonstrate remote-code execution was possible, arguing it was achievable in theory.
"The problem can only be triggered for configurations that use the --x509-alt-username option with an x509 extension (i.e. the option parameter starts with 'ext:')," said the OpenVPN team. "Extensive testing by Guido Vranken gives confidence that this function is very unlikely to fail in real-world usage (using subjectAltName or issuerAltName extensions) for other reasons than memory exhaustion."
The second bug, CVE-2017-7520, relates to how OpenVPN behaves when it's used to connect to a Windows NTLM version 2 proxy. A man-in-the-middle attacker between the client and the proxy server can either crash the client or snatch the password to the proxy from a memory leak. According to the VPN software's team:
If clients use a HTTP proxy with NTLM authentication (i.e. "--http-proxy <server> <port> [<authfile>|'auto'|'auto-nct'] ntlm2"), a man-in-the-middle attacker between the client and the proxy can cause the client to crash or disclose at most 96 bytes of stack memory. 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.
Vranken also turned up two remote server crashes (CVE-2017-7508 and CVE-2017-7522) triggered by sending malformed IPv6 packets or by sending malformed data post-authentication, and a couple of other bugs that don't constitute vulnerabilities.
Vranken's post includes a useful discussion of how he got around architectural features of OpenVPN that get in the way of fuzzing – for example, “OpenVPN executes external programs like ipconfig and route to modify the system’s networking state. This is not acceptable within a fuzzing environment.”
He also notes that a fuzzer has to be careful of OpenVPN's use of direct access to resources like files and networking, because “You certainly don’t want the fuzzer to end up writing random files and sending data to random IP’s.” Finally,
ASSERT() statements in the code have to be worked around so the fuzzing doesn't “abort after 2 seconds.” ®
PS: Keep an eye on WireGuard, a GPL-licensed, strong and lean alternative to OpenVPN.