| Version 21 (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 follows the Robustness Principle
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 as well. The management interface follows the Robustness Principle. The essence of this principle is:
"Be conservative in what you send, be liberal in what you accept"
By not causing any fatal behaviour, closing the management interface connection, etc when invalid data is received, the management interface proves it is quite robust and stable.
* note * - I'm not sure I'd emphasize it that way. This often-quoted sentence has led to quite a bit of undefined behaviour due to software accepting stuff it should have rejected outright. So maybe we just claim "this is the design of the management interface so clients can test availability of new commands without disturbing operation"...
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.
5. The management interface's availability is unpredictable
Any attempted attacks against the management interface needs to target specific configurations. There are no defined standard TCP port for the management interface. The simplistic approach going via a web browser, which the initial proof-of-concept uses, will only work with configurations where the management port number and is known. For a broad scale attack, the exploit code needs to implement a way to detect the management port by parsing an OpenVPN configuration file, figuring out which ports are used by an OpenVPN process or even implement a port scanner. It is possible to do so, but we consider the XMLHTTPRequest payload to be impractical. It might be a different attack vector outside of the web browser (including e-mail clients capable of running Javascript code in HTML formatted messages), but that means it needs to run fairly efficient code which has been downloaded separately in advance. At this level, OpenVPN itself is the least of concern - the system will at that point already be compromised.
In addition the vast majority of configurations making use of the management interface already has connected to the management interface, so this exploit will not be able to execute its task. And in cases where the exploit code can read the OpenVPN configuration file or manages to retrieve a list of which ports OpenVPN makes use of, the target machine has a much bigger issues than the OpenVPN management interface itself. In these cases this attack vector is irrelevant.
It can be argued that there might be a race condition between the service process connecting to the OpenVPN management interface and a web/XMLHTTPRequest-enabled exploit. But this is also a highly speculative argument. It essentially means the victim needs to be on a web page (or viewing an HTML formatted e-mail message allowing Javascript execution) running the exploit code and then the user connects to a VPN tunnel where the management port number is already known (there is no time to do a full blown port scan). Plus it needs to be able to connect to the management interface before the VPN GUI process starting the OpenVPN process.
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, yet again 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 (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 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
