OpenVPN 2.4.0, the NDIS6 TAP Driver for Windows, the Windows GUI, and Linux versions were evaluated. This release included a number of new features including control channel encryption.
QuarksLab found:
1 Critical/High Vulnerability CVE-2017-7478
1 Medium Vulnerability CVE-2017-7479
5 Low or Informational Vulnerabilities / Concerns
This public disclosure of these vulnerabilities coincides with the release of OpenVPN 2.4.2 which fixes all of the high priority concerns.
The Fixes:
Because of this audit, the OpenVPN development team has issued a number of fixes in OpenVPN 2.4.2.
The fixes include:
- Correction of a pre-authentication Denial of Service attack. An attacker can crash any OpenVPN client or server without any credentials or keys.
- Correction of an authenticated user Denial of Service attack. An attacker can crash an OpenVPN client or server using an AEAD mode cipher by sending crafted data to exhaust the packet counter. Requires authentication.
- Correction of issues in mbedtls (PolarSSL) X509 certificate handling. Verify return values of mbedtls_x509_dn_gets and mbedtls_x509_serial_gets correctly.
- Correction of usernames and passwords not being properly erased. for the new bootloader. (keystrokes not erased after authentication)
- Correction of null pointer dereferences. Because this issue is low-severity and not exploitable, this fix is reserved for a future release.
- Correction of service handling for OpenVPN GUI. The OpenVPN GUI did not properly terminate the service when closed.
- Improvements to documentation of the OpenVPN protocol. Improving transparency of functionality for developers working with the OpenVPN protocol.
- Updates to user documentation for other vulnerabilities that can be closed by user practices. Such as selecting more secure options, and deprecating antiquated options that are unsafe.
Furthermore the following was affirmed:
- When using OpenSSL, OpenVPN uses the RAND_bytes function for entropy exclusively. It appears to utilize it correctly with proper error handling.
- When using mbedTLS, OpenVPN uses the mbedtls_ctr_drbg_random function for entropy exclusively. It appears to utilize it correctly with proper error handling.
- When generating “non critical” random values, OpenVPN uses a custom algorithm that is non-standard but cryptographically sound.
- OpenVPN contains some legacy code related to end-of-life versions of OpenSSL that are no longer supported.
The full audit report can be accessed below, please do not direct link to the audit report, as we would like visitors to see our synopsis and donation links before viewing the full audit. Thank you.
https://ostif.org/wp-content/uploads/2017/05/OpenVPN1.2final.pdf
There was also another security review performed by Dr Matthew Green at Cryptography Engineering paid for by Private Internet Access. You can access this security evaluation here:
https://privateinternetaccess.com/blog/2017/05/openvpn-2-4-evaluation-summary-and-report/
Cryptography Engineering focused on the cryptography aspects of OpenVPN, and gave a list of recommended changes to improve the general cryptographic strength of OpenVPN.
- Correction of authentication token handling in TLS auth while in an error state. This has a commit in the 2.4 branch and will be fixed in a future release. It is low-impact.
- Potential loss of privacy with TLS auth or TLS crypt IV collision. The OpenVPN team is updating documentation and disagrees with the wording of a “total loss of privacy”. These functions protect already encrypted data with a second layer of encryption.
- Removal of the –no-IV option. The OpenVPN team has slated this option for deprecation and will be eliminated entirely in OpenVPN 2.5 and later.
- Removal of the –no-replay option. The OpenVPN team has stated that this feature is for debugging only, and should not be used outside of that context.
- Removal of the –reneg-bytes option. The OpenVPN team has stated that this will break configurations of OpenVPN that use One Time Pads, and needs to be left in for compatibility.
- Increase the strength of default encryption options. OpenVPN 2.4 and greater has stronger defaults in that cipher negotiation is used and defaults to AES-256-GCM, while also allowing stronger future ciphers to be supported provided that both the client and server support it.
- Warn about insecure modes of operation. OpenVPN will now issue a serious warning when –cipher none or –auth none is used.
- Remove system() from sample authentication plugin. There is a commit for this fix ready for a future release, likely for 2.4.3 or 2.4.4.
- Removal of –script-security 3. The OpenVPN team disagrees with the severity of the safety risks in the recommendation. The command will remain as-is, possibly with a documentation change.
- Removal of –tls-verify due to non-specific vulnerability. The OpenVPN team failed to find any issues with the current implementation.
- Warn users about compression use. As of 2.4.3 and higher, users will be warned about the risks of combining compression with streamed data.
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.
Please donate to OSTIF if you want us to continue this valuable work. We plan to continue this project indefinitely, as long as the community continues to support us. Every donation and every person you tell about OSTIF makes the Internet stronger, and safer.
I’d also like to extend a special thank you to Fred, Jean-Baptiste, Gabriel and Jordan at QuarksLab for conducting this audit, to Samuli and OpenVPN Technologies for their enthusiastic participation and the OpenVPN communities’ continued development of this crucial open-source software, and to the coalition of 33 companies and all of our individual donors for the funding to make this audit possible. We have all made the digital world a little bit safer for all of us.