Full-tunnel VPN DNS leakage regression

Bug #1754671 reported by dwmw2 on 2018-03-09
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Fix Released
network-manager (Ubuntu)
Olivier Tilloy

Bug Description

* Impact

When using a VPN the DNS requests might still be sent to a DNS server outside the VPN when they should not

* Test case

Configure the system to send all the traffic to a VPN, do a name resolution, the request should not go to the public DNS server (to be checked by capturing the traffic by example with wireshark)

* Regression potential

The code change the handling of DNS servers when using a VPN, we should check that name resolution still work whne using a VPN in different configurations


In 16.04 the NetworkManager package used to carry this patch:

It fixed the DNS setup so that when I'm on the VPN, I am not sending unencrypted DNS queries to the (potentially hostile) local nameservers.

This patch disappeared in an update. I think it was present in 1.2.2-0ubuntu0.16.04.4 but was dropped some time later.

This security bug exists upstream too: https://bugzilla.gnome.org/show_bug.cgi?id=746422
It's not a *regression* there though, as they didn't fix it yet (unfortunately!)

CVE References

dwmw2 (dwmw2) on 2018-03-09
information type: Private Security → Public Security

Confirming this is broken. Dropping the patch 0001-dns-use-DBus-to-make-dnsmasq-nameserver-changes.patch in network-manager (1.2.4-0ubuntu0.16.04.1) was done, but it looks like not all the code in that patch was actually upstream.

Changed in network-manager (Ubuntu):
status: New → Confirmed
importance: Undecided → High
tags: added: regression-update
dwmw2 (dwmw2) wrote :

This is CVE-2018-1000135. For some reason the 'Link to CVE' option above doesn't seem to work.


Will Cooke (willcooke) on 2018-03-26
tags: added: incoming rs-bb-
tags: added: rls-bb-incoming
removed: incoming rs-bb-
Changed in network-manager (Ubuntu):
assignee: nobody → Olivier Tilloy (osomon)
tags: removed: rls-bb-incoming
Changed in network-manager:
importance: Unknown → Medium
status: Unknown → Confirmed
Olivier Tilloy (osomon) wrote :

There's active work going on upstream (see https://bugzilla.gnome.org/show_bug.cgi?id=746422 and https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=bg/dns-bgo746422) to fix the issue.

https://bugzilla.gnome.org/show_bug.cgi?id=746422#c36 explains how.

Once in master, it would probably be doable to backport those changes (including https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=b2f306ac3d84283fdebb225079f354afb8c2a752) to the 1.10 branch, which is what's in bionic (1.10.6-2ubuntu1). Backporting to xenial (currently 1.2.6-0ubuntu0.16.04.2) would likely be an entirely different story.

Changed in network-manager:
status: Confirmed → Fix Released
Gijs Molenaar (gijzelaar) wrote :

Is it possible to upload a fixed package to bionic backports?

fessmage (fessmage) wrote :

Same question, will it be backported to Ubuntu 18.04 ?

Olivier Tilloy (osomon) wrote :

See the discussion in the upstream bug report. The fix is in the master branch and needs to be backported to the 1.10 series so that we can pick it up in bionic.

Olivier Tilloy (osomon) wrote :

This is fixed in the 1.12 series of network-manager (1.12.0 release), so cosmic and dingo are not affected.

Changed in network-manager (Ubuntu):
status: Confirmed → Fix Released
assignee: Olivier Tilloy (osomon) → nobody
Olivier Tilloy (osomon) wrote :

The fix was backported to the upstream 1.10 series.

Sebastien Bacher (seb128) wrote :

I've updated the description for the SRU but if someone had a better description of a testcase that would be welcome

description: updated

Hello dwmw2, or anyone else affected,

Accepted network-manager into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/network-manager/1.10.14-0ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in network-manager (Ubuntu Bionic):
status: Confirmed → Fix Committed
tags: added: verification-needed verification-needed-bionic
Olivier Tilloy (osomon) wrote :

Please test and share your feedback on this new version here, but refrain from changing the verification-needed-bionic tag for now. This new version includes many changes and we want to give it an extended testing period to ensure no regressions sneak in, before it is published to bionic-updates. Thanks!

Steve Langasek (vorlon) wrote :

How does this proposed change relate to LP: #1726124? Are users who are currently relying on correct split DNS handling by network-manager+systemd-resolved in bionic going to see this regress and have all DNS requests now sent over the VPN when they aren't supposed to?

fessmage (fessmage) wrote :

I installed package of network-manager 1.10.14-0ubuntu1 from bionic-proposed, and can confirm that version fixed dns leak: now when vpn connection established it gets `DNS Domain: ~.` in systemd-resolve automatically, so no more needed to manually apply command `systemd-resolve -i tun0 --set-domain=~.`. This positively fix dns leakage, verified by dnsleaktest.com

Olivier Tilloy (osomon) wrote :

@Steve (sorry for the late reply): not sure how that relates to bug #1726124, but in my limited understanding of the changes, they shouldn't regress the split-DNS use case.

Some relevant pointers to better understand the fixes and their context:

 - https://bugzilla.gnome.org/show_bug.cgi?id=746422 (particularly comments 8 and 26)

 - https://wiki.gnome.org/Projects/NetworkManager/DNS

 - https://gitlab.freedesktop.org/NetworkManager/NetworkManager/blob/nm-1-10/NEWS

dwmw2 (dwmw2) wrote :

network-manager-1.10.14-0ubuntu1 does seem to fix the DNS problem here; thanks.

dwmw2 (dwmw2) wrote :

Hm, that didn't last long. Now it isn't looking up *anything* in the VPN domains. It's all going to the local VPN server. I don't know what changed.

dwmw2 (dwmw2) wrote :

Not sure what happened there. It was looking up *some* names in the $COMPANY.com domain on the VPN, but others not, consistently. I couldn't see a pattern.

I have manually set ipv4.dns-search="~." and ipv4.dns-priority=-1 and now it does seem to be behaving. However, this shouldn't be necessary. This VPN has non-split routing and shouldn't it have non-split DNS too, by default? I shouldn't have to change the configuration, just to get back to the secure behaviour which used to work.

fessmage (fessmage) wrote :

@dwmw2, as far as i understand, you should configuring DNS through systemd-resolve only. Try remove your edits from `/etc/NetworkManager/system-connections`, or even delete your connections from NetworkManager interface, and create new. After that, establish vpn connection and see at `systemd-resolve --status`, you should get something like this:

Link 3 (tun0)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: xx.xx.xx.xx
          DNS Domain: ~.

Link 2 (enp3s0)
      Current Scopes: DNS
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers:
          DNS Domain: local.domain

Where local.domain was received from DHCP server in local network. In that case you will send DNS requests in local.domain to local DNS server, and all other DNS requests - over VPN. That is expected behaviour. If you get this, but you have needs for redirecting DNS requests for some domain through other route (let's say, requests to local2.domain2, without VPN), you can do this with next command: `systemd-resolve -i enp3s0 --set-domain=local2.domain2`

Taylor Raack (track16) wrote :

I can also confirm that the network-manager package version 1.10.14-0ubuntu1 from bionic-proposed fixes the issue.

To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.