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.
blog.quarkslab.com/security-assessment-of-openvpn.html
www.prweb.com/releases/2017/05/prweb14326488.htm
ostif.org/the-openvpn-2-4-0-audit-by-ostif-and-quarkslab-results/
ostif.org/the-openvpn-2-4-0-audit-by-ostif-and-quarkslab-results/
threatpost.com/openvpn-to-undergo-cryptographic-audit/122349/
www.privateinternetaccess.com/blog/2017/05/openvpn-2-4-evaluation-summary-report/#section_6