Security with .ovpn files; arbitrary code execution; pushing DNS on linux

[ourvpn 0]

Hi,

 

It seems that the openvpn linux client does not deal too well with DNS settings -- it doesn't update them itself anyway based on the pushed settings. The suggested solution for this on https://airvpn.org/topic/9608-how-to-accept-dns-push-on-linux-systems-with-resolvconf/?p=10827 is to add the lines

 

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

to the appropriate .opvn script. Looking into this, it seems enabling script-security 2 allows "calling of built-in executables and user-defined scripts".

 

1. Does this mean that if I were to download and run a .ovpn config script from your configurator, you could execute arbitrary code on my system, with superuser privileges, by putting the appropriate lines in the file?
    
2. Can the OpenVPN server 'push' directives that cause scripts to be executed by the client? Is there a reference that explicitly says this is not possible? Can the server push script-security 2? (Surely not.)
    
3. Does the Network Manager method for connecting to the VPN allow script execution through settings in the .ovpn file?
    
4. I guess if I am adding the lines to the .ovpn file, I will be inspecting it anyway. But in view of Q2 above, is there a way of avoiding giving the script elevated abilities while still getting DNS to work? Can I manually run /etc/openvpn/update-resolv-conf after openvpn? Is there a neat way of automating this in a single script?

Many thanks for answers and/or references to these.

 

[Staff 9972]

Hello!

 

1. No, you can't run a .ovpn file, it is not a script, but maybe you wanted to ask something different. See answer 2 below, for clarifications. Anyway you don't need to trust us, just examine the .ovpn file, you'll see that no script is invoked (unless you explicitly write your own custom directives in the appropriate Configuration Generator field).

 

2. Yes, see here about what's pushable, and limitations http://openvpn.net/index.php/access-server/docs/admin-guides/401-how-to-setup-client-scripting-in-openvpn-access-server.html. In case a script (bash or a built-in Python sub-set implementation) is pushed, as well as with its execution request, the user must anyway approve it, before it can run, or configure (as root) OpenVPN to run scrips silently. Additionally, from the logs or from OpenVPN output, you can check all the pushes performed by the servers, for your peace of mind.

 

3. To be tested. nm does not pass to OpenVPN the directive 'explicit-exit-notify', for example, so it might have other limitations.

 

4. You could manually set the nameserver, or you can run OpenVPN as a normal user, instead of root, preparing the correct environment:

https://community.openvpn.net/openvpn/wiki/UnprivilegedUser

 

For more information, please have a look at the OpenVPN manuals:

http://openvpn.net/index.php/open-source/documentation/manuals.html

 

Kind regards

[ourvpn 0]

Thanks.

 

1. You are right; what I wrote was not quite what I meant. What I meant was: if I run 

sudo openvpn file.ovpn

where I have obtained file.ovpn from a third party (such as yourselves), then that can essentially cause arbitrary scripts to be executed on my computer, and as far as I can tell with superuser privileges. It seems to me that this is accurate. Like you say, one can get round this issue by inspecting the .ovpn file before one runs openvpn with it.

 

2. Thanks for this reference. As I understand it, it is not possible for the server to push directives to cause scripts to be executed on my system without my knowledge, at least if I have inspected the .ovpn file. I would have to take several steps for it to be possible.

 

3. Thanks. Would be good to know.

 

4. Thanks for the link to running openvpn underprivileged. Just to confirm, however: do you agree that if I have inspected the .ovpn file and then added script-security 2 and the up/down directives, this should be safe regardless of what settings might be pushed by the server?

 

Thanks again.