Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DNS leaking #160

Closed
fkooman opened this issue Sep 24, 2018 · 58 comments

Comments

@fkooman
Copy link
Member

commented Sep 24, 2018

See systemd/systemd#7182 (comment)

This is on Ubuntu 18.04 LTS at least, maybe other systems as well.

Is there a way to set the DNS domain to "." for the VPN interfaces?

@fkooman

This comment has been minimized.

Copy link
Member Author

commented Sep 24, 2018

You can test DNS leakage by going to https://www.dnsleaktest.com/ (Extended Test).

If you see your own ISP there (while connected to VPN), it is leaking DNS, if you see the DNS server of the VPN provider it is not leaking.

@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Oct 3, 2018

@fkooman that dnsleaktest website states we can solve this issue by adding block-outside-dns to the openvpn config file. When I download a configuration from demo.eduvpn.nl this statement has not been added. Does this not properly work in our case?

@fkooman

This comment has been minimized.

Copy link
Member Author

commented Oct 3, 2018

--block-outside-dns only works on Windows:

   --block-outside-dns
         Block  DNS  servers  on  other  network  adapters to prevent DNS
         leaks. This option prevents any application from  accessing  TCP
         or  UDP  port  53  except one inside the tunnel. It uses Windows
         Filtering Platform (WFP) and works on Windows Vista or later.

         This option is considered unknown on non-Windows  platforms  and
         unsupported  on  Windows  XP, resulting in fatal error.  You may
         want to use --setenv opt or --ignore-unknown-option  (not  suit‐
         able  for  Windows  XP) to ignore said error.  Note that pushing
         unknown options from server does not trigger fatal errors.

This option is already used, it is part of the options pushed to the client during connect, but as stated above, ignored on Linux, you can see it being ignored if you watch client log:

Wed Oct  3 11:46:44 2018 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:1: block-outside-dns (2.4.6)
@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Oct 3, 2018

manually adding block-outside-dns to a ovpn file and then importing it network manager doesn't seem to have any effect.

@fkooman

This comment has been minimized.

Copy link
Member Author

commented Oct 3, 2018

manually adding block-outside-dns to a ovpn file and then importing it network manager doesn't seem to have any effect.

That's because it is not supported on Linux...

@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Oct 3, 2018

So normally the DNS server would be configured by DHCP right? Disabling automatic configuration and setting the Google DNS servers solves it for some tests, but not all (just making notes). I don't see much dbus exposed options otherwise.

@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Oct 3, 2018

There are some workarounds in the bug reports, but I find it quite scary and fragile to manually alter peoples configs outside dbus.

@fkooman

This comment has been minimized.

Copy link
Member Author

commented Oct 3, 2018

Maybe this can help, at least get inspiration from it. https://github.com/jonathanio/update-systemd-resolved

@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Oct 3, 2018

ah, interesting, thanks.

@fkooman

This comment has been minimized.

Copy link
Member Author

commented Oct 3, 2018

Manually fixing it: systemd-resolve -i tun2 --set-domain=~. where tun2 is your VPN interface.

@fkooman

This comment has been minimized.

Copy link
Member Author

commented Oct 3, 2018

If you then use systemd-resolve --status you see this:

Link 5 (tun2)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 192.87.106.106
                      192.87.36.36
                      2001:610:1:800a:192:87:106:106
                      2001:610:3:200a:192:87:36:36
          DNS Domain: ~.
@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Oct 3, 2018

yeah, that seems to do the trick. Let me see if we can do this over dbus somehow.

@fkooman

This comment has been minimized.

Copy link
Member Author

commented Oct 3, 2018

There is a package on Ubuntu for integration with resolved: openvpn-systemd-resolved, it is a bash script that uses busctl to send commands over DBUS. So that should not be too hard to port to Python :)

Maybe it is enough to just integrate the up/down in the config file, but I'm not sure this actually works with NetworkManager?

@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Oct 3, 2018

Debian seems to have a systemd-resolve command (part of systemd), but I can't verify if it works properly at the moment due to the #157. centos7 seems to be missing this command, it only has a systemd-resolved package.On Fedora it seems to work.

@fkooman

This comment has been minimized.

Copy link
Member Author

commented Oct 3, 2018

On Fedora it already worked. There was no need to do anything there as Fedora does not use systemd-resolved.

This is currently only relevant for Ubuntu 18.04 as mentioned in the OP.

@fkooman

This comment has been minimized.

Copy link
Member Author

commented Oct 3, 2018

@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Oct 3, 2018

aha, good.

@fkooman

This comment has been minimized.

Copy link
Member Author

commented Oct 3, 2018

I guess it should be possible (using DBUS call?) to determine if systemd-resolved is used, and only in that case use the 'fix' without hardcoding information regarding specific distributions.

@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Oct 3, 2018

The up and down script parameters are completely ignored by NetworkManager when set in an ovpn config file. At least it doesn't add an invalid config as with tls-crypt.

@fkooman

This comment has been minimized.

Copy link
Member Author

commented Oct 3, 2018

I think this would be best solved in the NetworkManager OpenVPN plugin. Probably that's the only reliable solution...

Otherwise the app would have to do this after each connect (it can listen for dbus events?), if the default gateway is set for that particular connection.

@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Oct 3, 2018

So the quick and dirty solution would be to detect what is dist + version, if affected run that systemd-resolv once connected (detectable by dbus event). But i'm looking for a less hacky way.

@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Oct 3, 2018

manually calling the update-systemd-resolved script doesn't seem to solve the problem.

@fkooman

This comment has been minimized.

Copy link
Member Author

commented Oct 3, 2018

Calling it from up in the configuration file populates some environment variables before running the script, there is no need to use the script itself, you can via dbus set the DNS Domain to ~. as shown above.

I'm surprised there is no issue yet for this: https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/issues

I'll create one.

@fkooman

This comment has been minimized.

@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Oct 3, 2018

We can manipulate the systemd-resolved using the org.freedesktop.resolve1.Manager interface:

https://www.freedesktop.org/wiki/Software/systemd/resolved/

@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Oct 3, 2018

this is the python-dbus equivalent, took me a while to figure out again how dbus types works:

bus = dbus.SystemBus()

node = "/org/freedesktop/resolve1"
bus_name = 'org.freedesktop.resolve1'
interface = "org.freedesktop.resolve1.Manager"

resolve_proxy = bus.get_object(bus_name=bus_name, object_path=node)
resolve_iface = dbus.Interface(object=resolve_proxy, dbus_interface=interface)

resolve_iface.SetLinkDomains(6, ((".", True),))
@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Oct 3, 2018

The resolve1 service uses something called 'links', which is the interface index. Unfortunately, the index is not exported by NetworkManager, and the resolve1 interface doesn't expose the interface names.

the update-systemd-resolved script uses the ip command to figure out what the link id is:

$ ip link show dev tun0
6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 100
    link/none
@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Oct 3, 2018

looks like the bug has been reported at Ubuntu before https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1690860

@fkooman

This comment has been minimized.

Copy link
Member Author

commented Oct 3, 2018

There are indeed a number of reports, but none really explain what is going on.

@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Oct 8, 2018

What do you mean? that is the default, right?

Btw, i'm leaving this issue open for now, I'm not confident this is robust enough:

https://github.com/eduvpn/python-eduvpn-client/blob/master/eduvpn/security.py#L32

Although I didn't manage to break it yet.

it might break when people multiple active tun.

@gijzelaerr gijzelaerr reopened this Oct 8, 2018
@fkooman

This comment has been minimized.

Copy link
Member Author

commented Oct 8, 2018

What do you mean? that is the default, right?

Sure, but not necessarily. There are VPN profiles that do not set the default gateway, only push certain IP ranges to the client to be routed over the VPN, in that case we currently do not even push DNS servers to the client and the already configured DNS servers should be used.

@fkooman

This comment has been minimized.

Copy link
Member Author

commented Oct 8, 2018

I'm not confident this is robust enough

The only real fix is that they fix this in Ubuntu by backporting the fix to their version of NetworkManager. Can you also open a bug report there?

@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Oct 8, 2018

afaik, for now this code is the equivalent of running systemd-resolve -i <device> --set-domain=~. fo r every active connection. If there are more requirements i'm all ears and they should be written down.

@fkooman

This comment has been minimized.

Copy link
Member Author

commented Oct 8, 2018

If there are more requirements i'm all ears and they should be written down.

  1. Only do this for the VPN device you are currently activating;
  2. Only do this when the VPN you just activated claims the default gateway.
@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Oct 8, 2018

I'm not confident this is robust enough

The only real fix is that they fix this in Ubuntu by backporting the fix to their version of NetworkManager. Can you also open a bug report there?

which package upgrade would solve the problem?

@fkooman

This comment has been minimized.

Copy link
Member Author

commented Oct 8, 2018

which package upgrade would solve the problem?

network-manager

As mentioned here: https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/issues/10

@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Oct 8, 2018

If there are more requirements i'm all ears and they should be written down.

  1. Only do this for the VPN device you are currently activating;
  2. Only do this when the VPN you just activated claims the default gateway.

ok then i need to figure out how to find out if the vpn claims the default gateway, which will take more time.

@fkooman

This comment has been minimized.

Copy link
Member Author

commented Oct 8, 2018

Maybe we should try the upstream approach first, i.e. have NetworkManager fixed in Ubuntu...

@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Oct 8, 2018

Maybe we should try the upstream approach first, i.e. have NetworkManager fixed in Ubuntu...

It depends if they judge it as a security bug. If not it is the same as with Debian, people need to have the backports repo enabled, which is not enabled by default. Which would make the installation more complex. Although probably can be a oneliner.

@fkooman

This comment has been minimized.

Copy link
Member Author

commented Oct 8, 2018

I think enabling backports is not such a bad thing, as long as there is a clear reason why it is needed...

@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Oct 8, 2018

reported upstream at Ubuntu, but since I marked it as a security issue it is not public yet.

@fkooman

This comment has been minimized.

Copy link
Member Author

commented Oct 8, 2018

Thanks! 💯

@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Oct 10, 2018

until now zero response, but here is the URL for when the issue becomes public https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1796648

@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Oct 11, 2018

still no response from package maintainer, contacted Ubuntu security team.

@gijzelaerr gijzelaerr self-assigned this Oct 12, 2018
@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Oct 13, 2018

The report is public now and status confirmed, they are investigating

@fkooman

This comment has been minimized.

Copy link
Member Author

commented Oct 14, 2018

The report is public now and status confirmed, they are investigating

Funny they make it public before investigating... Ah well. Hope they provide an update!

@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Oct 29, 2018

Nothing yet from Ubuntu. I've changed my mind and disabled the workaround. I don't think it is our responsibility to fix it, or at least I find it too risky to manipulate a users networking config outside of networkmanager, there are too many edge cases.

If you are running Ubuntu 18.04 you now get a warning:
screenshot from 2018-10-29 16-53-39

which links to the issue on the Ubuntu bug tracker.

@gijzelaerr gijzelaerr removed their assignment Oct 30, 2018
@fkooman

This comment has been minimized.

Copy link
Member Author

commented Oct 30, 2018

I've changed my mind and disabled the workaround. I don't think it is our responsibility to fix it, or at least I find it too risky to manipulate a users networking config outside of networkmanager, there are too many edge cases.

Agreed!

@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Oct 30, 2018

i'll leave this issue open until a backport or a fix has been uploaded.

@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Dec 19, 2018

there is now a CVE https://nvd.nist.gov/vuln/detail/CVE-2018-1000135

It seems a fix has been backported to network manager 1.10, which is pending a backport upgrade to bionic

https://code.launchpad.net/~osomon/network-manager/+git/network-manager/+ref/bionic-1.10.14-sru

@fkooman

This comment has been minimized.

Copy link
Member Author

commented Dec 19, 2018

Great! Will they also push it to "stable" at some point?

@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Dec 19, 2018

i don't fully understand their process, but I hope so. lets first see how the backport process will go.

@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented Dec 20, 2018

there is an issue for tracking the update to 1.10 in the main archive: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1809132

@gijzelaerr

This comment has been minimized.

Copy link
Collaborator

commented May 14, 2019

1.00 seems to have landed in the archives. Just did a test with a updated ubuntu bionic system and the issue seems to be resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
2 participants
You can’t perform that action at this time.