Changes between Version 21 and Version 22 of CVE-2018-7544


Ignore:
Timestamp:
04/25/18 14:38:04 (6 years ago)
Author:
David Sommerseth
Comment:

Updated according to several feedbacks

Legend:

Unmodified
Added
Removed
Modified

  • CVE-2018-7544

    v21 v22  
    2424
    2525
    26 === 3. Management interface follows the Robustness Principle ===
     26=== 3. Management interface is forgiving by design ===
    2727
    28 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 [https://en.wikipedia.org/wiki/Robustness_principle Robustness Principle].  The essence of this principle is:
    29 
    30 {{{
    31     "Be conservative in what you send, be liberal in what you accept"
    32 }}}
    33 
    34 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.
    35 
    36 *** 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"...
     28It 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.
    3729
    3830
    3931=== 4.  The management interface supports password authentication ===
    4032
    41 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.
     33Since 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.
    4234
    4335
    44 === 5.  The management interface's availability is unpredictable ===
     36=== 5.  The management interface's availability ===
    4537
    46 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.
     38The 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.
    4739
    48 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.
     40Another 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.
    4941
    50 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.
     42On 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.
    5143
    52 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.
     44Further, 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.
     45
     46Thus, this is a configuration and implementation issue of the service making use of the management interface.
    5347
    5448
    5549=== 6.  OpenVPN cannot protect users against improper configuration or usage by itself ===
     50
     51OpenVPN 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.
    5652
    5753OpenVPN (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.
    … …  
    6157 * 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-client}}} option.
    6258 * Wherever applicable, use a unix socket in favour of TCP sockets.
    63  * Enable password authentication when using a TCP sockets.
     59 * Enable password authentication, at least when using a TCP sockets.
    6460
    6561Not complying to these three simple points is considered a "you know what you are doing at your own risk" configuration.
    6662
    6763It 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.
     64
    6865
    6966=== Conclusion ===