| Version 22 (modified by , 6 years ago) (diff) |
|---|
[DRAFT] CVE-2018-7544: * DISPUTED * Remote Information Disclosure and Denial Of Service
Jose Antonio Pérez Piedra discovered a way to interfere with a running OpenVPN instance via the management interface, and reported this as a security issue to the OpenVPN developers. They disagreed with the assessment and classified as a (non-default) configuration problem. Jose disagreed with that and proceeded to get a CVE ID allocated (CVE-2018-7544).
Since the existence of a CVE will create insecurity and confusion for OpenVPN users, this page tries to clarify what this is about, why it is not seen as a security issue and why no code changes will be made to disallow the configuration variant in question.
Why do we dispute this CVE?
1. Management interface is disabled by default
OpenVPN does not enable the management interface by default. It has to be explicitly enabled. The documentation since the arrival of the management interface has stated:
It is strongly recommended that IP be set to 127.0.0.1 (localhost) to restrict accessibility of the management server to local clients.
It has also since OpenVPN 2.1 been possible to use a Unix socket instead of a TCP socket for the management interface on platforms where this is available. It is only the Windows platform which cannot work with a Unix socket out-of-the-box.
2. Management interface access is exclusive
The design around the management interface is to be exclusive to a single connection only. This is by design. A configuration setup which makes use of the management interface is expected to connect to it as soon as possible. Any other clients trying to connect to it will not be able to connect.
3. Management interface is forgiving by design
It is claimed to be an issue that the management interface accepts bogus/invalid input before and/or after valid management commands. This is by design. This allows users of the management to check for availability of features regardless of the OpenVPN version running without risking disruptions of the currently running process.
4. The management interface supports password authentication
Since early OpenVPN 2.0, the management interface has supported the use of a simple password authentication to gain access. This adds another layer of protection, especially when the management interface is used over TCP. But this is TCP where the communication is not encrypted. Due to the unencrypted nature of TCP, it should be clear this is not intended to be used over an insecure network, more commonly via localhost (127.0.0.1) - or even better, a unix socket.
5. The management interface's availability
The Windows GUI is the most commonly used OpenVPN interface on Windows, which facilitates the use of the management and has done that since OpenVPN 2.3_alpha1. OpenVPN on Windows prior to this release did not use the management interface. As of v2.3_alpha1 and since then, the management interface is configured with a random generated password for each tunnel instance. This password is unique per running instance and never re-used.
Another widely used management interface user on the client side the NetworkManager?'s OpenVPN plug-in. This has for a long time not used TCP connections, but uses Unix sockets.
On the server side, the OpenVPN Access Server is using the management interface as well. For VPN clients be able to establish a VPN connection, the management process must be connected to the management interface at all times. If it is not connected, clients will not be able to authenticate. Access Server is designed to ensure the management process is always connected to the OpenVPN server processes it is expected to manage.
Further, there exists no standard or recommended port number to use for the management interface. Thus an attacker is forced to do a local port scan and check if it is an OpenVPN management interface responding. In addition to this, the timing is also crucial. For an attacker to successfully gain control, it must do so before the legitimate management process gets a chance to connect. If there are implementers concerned about this race condition, they need to consider to use the --management-client option. This makes OpenVPN become a connecting client instead of a server accepting connections. The service process making use of the management interface with this option will then need to listen for the OpenVPN process to connect to itself.
Thus, this is a configuration and implementation issue of the service making use of the management interface.
6. OpenVPN cannot protect users against improper configuration or usage by itself
OpenVPN is often considered to be the Swiss Knife of VPNs, due to its flexibility and features. That means: There are some blades which will hurt you if not used properly, and some blades are worse than others.
OpenVPN (or any other network enabled service) can not protect itself or its users against incorrect configurations. If OpenVPN is configured to open a management interface, OpenVPN expects the management interface to be used according to its design. The core OpenVPN process (/usr/sbin/openvpn, openvpn.exe) itself is not aimed to be used by non-technical users directly, it is supposed to be used via a more user-friendly interface. For graphical desktops this is fairly obvious; there are plenty of end-user front-ends (OpenVPN GUI, Tunnelblick, Viscosity, NetworkManager, etc). For servers and headless computers, this most commonly happens via various service management tools (like init.d/upstart/systemd or Windows based service management tools). This is needed because the OpenVPN process needs elevated privileges to be able to configure the VPN tunnel and the network routing; these end-user front-ends takes care of handling this privilege escalation properly for the core OpenVPN process.
This essentially means:
- Any configuration using the management interface needs to have a management service connecting to the interface as soon as possible and keep the connection during the lifetime of the VPN tunnel; alternatively the management service is listening for the OpenVPN process to connect to by using the
--management-clientoption. - Wherever applicable, use a unix socket in favour of TCP sockets.
- Enable password authentication, at least when using a TCP sockets.
Not complying to these three simple points is considered a "you know what you are doing at your own risk" configuration.
It could also be argued that the management interface is enabled in configuration files provided by a VPN service provider or similar. Again, this is improper usage of OpenVPN if there are no management service process activating the core OpenVPN process. OpenVPN end-users should get the configuration file from a well-known and trusted source, if it has not already been installed by a system or network admin. OpenVPN itself cannot account for or try to protect users against using a configuration file from non-trusted source. Users who use OpenVPN configuration files downloaded from untrusted sources are taking much bigger risks than the possibility that their management interface gets abused.
Conclusion
OpenVPN does not enable management interface by default. Also, if the management interface is properly configured and used, there are no known security issues with it. Any configuration that enables the management interface over TCP without setting a password is considered improperly configured. Further, any configuration that enables the management interface without actually connecting to it is considered improper.
What has been done
The OpenVPN core developers acknowledge that the documentation has not been too explicit on the risks of using the TCP interface. But the core developers are at the same time surprised some might not find this obvious and clear for anyone making use of a TCP enabled service without a password.
Regardless, to make this explicit two patches has been added to better highlight such potential improper usage:
commit e5ee5121cbbeca6dcbee38dea5b40779e3f6da83
Author: David Sommerseth
Date: Wed Feb 28 14:19:17 2018 +0100
man: Reword --management to prefer unix sockets over TCP
It is more secure to use unix sockets instead of TCP ports for the
management interface, so reword it and provide some details why TCP is
not recommended.
Also re-arranged this section to be somewhat easier to read and clearer
on a few related details.
Signed-off-by: David Sommerseth
Acked-by: Gert Doering
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg16573.html
Signed-off-by: Gert Doering
(cherry picked from commit ec100d7e4ce7aaeb731c22b0d86826bf295df6cd)
This was added to the OpenVPN 2.4.5 release and updates the man page to explicitly state:
BEWARE of enabling the management interface over TCP. In these
cases you should ALWAYS make use of pw-file to password protect
the management interface. Any user who can connect to this TCP
IP:port will be able to manage and control (and interfere with)
the OpenVPN process. It is also strongly recommended to set IP
to 127.0.0.1 (localhost) to restrict accessibility of the man-
agement server to local clients.
Further the following patch is in the queue for the OpenVPN 2.4.6 release
commit ab218befec67dc0f5bb08973d2ec3476350f9ab3
Author: David Sommerseth
Date: Wed Feb 28 14:19:18 2018 +0100
management: Warn if TCP port is used without password
It is not recommended to use --management on a TCP port without also
adding a password authentication, as this can easily be abused by other
users or processes being able to connect to the managmement interface.
Thus issue a warning that this configuration is strongly discouraged.
Signed-off-by: David Sommerseth
Acked-by: Gert Doering
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg16574.html
Signed-off-by: Gert Doering
(cherry picked from commit 4db7715a3aa62f2e8d8234c1852fb141f62318e2)
This results in the following line to be seen in the logs whenever the management interface is enabled on a TCP port without a password enabled:
WARNING: Using --management on a TCP port WITHOUT passwords is STRONGLY discouraged and considered insecure
