Two security audits of OpenVPN were recently carried out to look for bugs, backdoors, and other defects in the open source software; one found the software was cryptographically sound, while another found two legitimate vulnerabilities.
The news comes after it was announced in December the SSL VPN solution was in the middle of undergoing an audit – and that Matthew D. Green, PhD, a well-respected cryptographer and a professor at Johns Hopkins University was overseeing it.
Green’s audit, performed under the moniker of Cryptography Engineering LCC and funded by VPN provider Private Internet Access, wasn’t the only one however. Funded by the Open Source Technology Improvement Fund (OSTIF), QuarksLab, the Paris-based firm that handled VeraCrypt’s audit last summer, also carried out its own audit.
Both groups shared their findings last Thursday, the same day OpenVPN pushed out an updated version of the VPN service.
Green’s audit, carried out from December 2016 to February 2017, found a handful of low and medium issues but no major vulnerabilities.
In fact, Green’s audit generally lauds OpenVPN’s overall cryptographic design, calling it solid. He does warn that some implementations could “undermine a user’s ability to deploy a secure VPN solution” however.
In particular, OpenVPN offers configuration options that users can implement to fine tune how the service handles encryption and authentication. Green is advocating either deprecating or removing all of the options (-prng, -no-iv, -no-replay, to name a few) in future versions of the platform.
He’s also encouraging OpenVPN developers to periodically run static and dynamic analysis tools – like those he used to carry out the audit – before each release to identify any vulnerabilities that may work their way into the code.
“Given the numerous options and features provided by OpenVPN, vulnerabilities may crop up from certain feature combinations,” Green wrote in the audit, “This will be an ongoing challenge for OpenVPN developers to catch these problems early as the code base continues to evolve and expand.”
Some of the minor bugs that Green found include a sensitive authentication token that in some instances – such as if the TLS certificate common name or certificate hashes have changed – isn’t wiped. He also found a handful of possible NULL pointer dereferences and an issue with the OpenVPN feature TLS-crypt.
TLS-Crypt, which is supposed to act as a hardening layer on top of TLS by TLS hiding certificate and other tunnel configuration information, may not be ready for primetime, Green cautions.
Exploiting the feature probably wouldn’t be easy and it’s likely the worst that could happen would be a denial of service attack – but Green is stressing OpenVPN revisit the way TLS-crypt is constructed before deploying it en masse.
Green’s audit, which focused moreso on the cryptographic aspects of OpenVPN, mostly specialized in recommendations. The paper is heavy on upgrades – making SHA-2 and AES the defaults for message digests and block ciphers, rewriting plugins, and better warning users about the risks of compression on encrypted channels.
QuarksLab’s audit, carried out by three engineers over the course of seven weeks – from Feb. 15 to April 7 – was more of a security evaluation of the software. The audit, which was done on OpenVPN 2.4.0, found two bugs in the software that were fixed last week.
The engineers, Jean-Baptiste Bédrun, Jordan Bouyat, and Gabriel Campana, described the vulnerabilities and the general impression that QuarksLab got from the audit in a blog post last Thursday.
The first vulnerability, a high severity pre-authentication denial of service (CVE-2017-7478) could have been triggered by a packet with an unexpected payload size and led to a server shutdown. The second, a medium severity post-authentication denial of service bug (CVE-2017-7479) could have enabled an authenticated client to shutdown the server using AEAD ciphers and packet Id exhaustion.
Both vulnerabilities, in addition to five low severity vulnerabilities, were addressed in OpenVPN 2.4.2 and 2.3.15, released on Thursday.
While QuarksLab’s engineers commend OpenVPN developers for their work and acknowledge the company regularly follows best practices for secure development, it also feels that what OpenVPN is trying to do, make future versions of the project compatible with old ones, can be inherently difficult. This sometimes “has a negative impact on the overall security of the project,” QuarksLab engineers said.
Bédrun, Bouyat, and Campana said the project’s old code isn’t helping matters.
“The source code is monolithic and difficult to apprehend, and the lack of developer documentation does not make its understanding better,” the engineers wrote, “But the main issue is that subtle bugs can be caused by this complexity, and code review of recent commits is tough.”
OSTIF said in a blog entry on Thursday that regardless of the nitty gritty, it sees both audits as a net-win for the consumer.
“OpenVPN is much safer after these audits, and the fixes applied to the OpenVPN mean that the world is safer when using this software. We have verified that the OpenVPN software is generally well-written with strong adherence to security practices,” the blog entry reads.
OpenVPN, for it’s part, fixed the bugs QuarksLab found and thanked the engineers – and the OSTIF – for their work via a press release last Thursday.
“OSTIF funded audits look for bugs, back doors, or other potential defects. The organization is a strong and independent advocate for free and open software that we are pleased to be part of,” Francis Dinha, CEO and Co-Founder of OpenVPN Inc. said last week following the audit.
