Quarkslab was hired by OSTIF to perform a security assessment of OpenVPN 2.4.0. We focused on code and cryptography assessment. Results are briefly described in this blog post, and full report is available at its end.
Synopsis
In November 2016, the Open Source Technology Improvement Fund (OSTIF) started a fundraising campaign to assess the security of OpenVPN. Mid December, the fund raising has reached its goal, and Quarkslab was selected to perform the assessment.
The review targeted version 2.4.0 and was performed by 3 engineers between 15 February 2017 and 7 April 2017, for a total of 50 man days of effort. Issues were reported to the OpenVPN team and have been fixed in OpenVPN 2.4.2.
The full report is made available on this blog post [1].
Scope
This evaluation focuses on the source code of OpenVPN 2.4.0, on OpenVPN GUI 11.4.0.0 and on the TAP driver used by OpenVPN for Windows. The scope of the audit includes Linux and Windows versions of OpenVPN.
Initially, OpenVPN for Android was part of the audit since the project uses OpenVPN code, but the source code specific to openvpn-ics was not audited due to a lack of time. We thus have excluded it from the audit.
OpenVPN 2.4.0 : http://build.openvpn.net/downloads/releases/openvpn-2.4.0.tar.xz (6f23ba49a1dbeb658f49c7ae17d9ea979de6d92c7357de3d55cd4525e1b2f87e)
OpenVPN GUI 11.4.0.0 : http://build.openvpn.net/downloads/releases/openvpn-gui-11.tar.gz (fac0608e0979e1d6f5cfed6a9e0f8a2caa2613df066a0419dc465e80698f0f44)
OpenVPN TAP driver 9.21.2 : http://build.openvpn.net/downloads/releases/tap-windows-9.21.2.tar.gz (2e98a4c8e9c81527a6c3aa383b7e6b6fafe12cde85fbf71fc87a0b644a30869a)
The cryptographic back ends (mostly OpenSSL) were explicitly excluded: only the soundness of their use was checked.
Key Findings
Only the main issues with a security impact are reported here. For a complete overview, refer to the report.
| Issue | Severity | Difficulty | Description |
|---|---|---|---|
| Pre-auth DoS CVE-2017-7478 | High | Low | A packet with an unexpected payload size during SSL handshake causes a server shutdown |
| Post-auth DoS CVE-2017-7479 | Medium | Medium | An authenticated client can shutdown the server using AEAD ciphers and packet Id exhaustion |
| Info leak | Low | High | Username and password can leak in very specific conditions |
| Cryptography | Info | N/A | Backward compatibility weakens encryption and authentication |
| Cryptography | Low | Low | Outdated authentication can be used without warning |
| Cryptography | Low | Low | mbed TLS provides weaker key cipher suites |
| Configuration | Low | Low | Insecure configurations to be removed from default builds |
Severity refers to the consequences of the bug.
Difficulty is the difficulty to trigger the vulnerability.
Fixes and new release
Quarkslab and OpenVPN teams have worked together to provide fixed 2.4.2 version of OpenVPN:
7 April 2017: report 0.2 sent to OpenVPN.
13 April 2017: report 1.0 sent to OpenVPN, adding the post-authentication denial of service.
14 April 2017: first comments from OSTIF and the OpenVPN security team.
25 April 2017: report 1.1 sent to OpenVPN, taking into account the comments from the OpenVPN team.
1 May 2017: new comments from the OpenVPN security team.
11 May 2017: updated report to version 1.2 and public release. Release of OpenVPN 2.4.2.
Conclusion
Since the beginning of the project, OpenVPN has followed the best practices for secure development. For examples, wrappers are used to avoid handling strings and buffers directly, assertions are used to avoid that the program ends up in an inconsistent state, secure functions of the C language are used, etc. Best practices of development make the discovery of memory corruption vulnerability unlikely. If vulnerabilities were to be found, logical or cryptographic bugs would be more likely.
OpenVPN developers are carrying out a hard work to make future versions of the project compatible with the older ones. However, this effort has a negative impact on the overall security of the project:
The source code is monolithic and difficult to apprehend, and the lack of developer documentation does not make its understanding better. But the main issue is that subtle bugs can be caused by this complexity, and code review of recent commits is tough.
The multitude of available options gives the ability to use OpenVPN in insecure configurations. Options which lower the security should be removed, to the detriment of retro-compatibility. It is also difficult to test the project in every possible configuration, and the probability of bugs in a specific configuration is high.
The Fox-IT initiative of a hardened version of OpenVPN heads in the right direction. For example, only some default secure encryption and message digests are kept, and the other ones are removed. Besides, some features and options considered as harmful are also removed. We think OpenVPN could integrate these changes and provide compilation options allowing to build such a hardened version for people who do not need backward compatibility.
Acknowledgements
We would like to thank OSTIF, and especially Derek Zimmer, for coordinating this effort, and the OpenVPN team for the quick and sharp feedback.
| [1] | Full report of the assessment |