Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1553634 - CVE-2018-1000135 Full-tunnel VPN misconfigures DNS servers, leaks private information
Summary: CVE-2018-1000135 Full-tunnel VPN misconfigures DNS servers, leaks private inf...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lubomir Rintel
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-03-09 08:51 UTC by David Woodhouse
Modified: 2020-01-26 08:45 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-01-26 08:45:16 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 746422 0 Normal RESOLVED [CVE-2018-1000135] Unencrypted DNS queries leaked outside full-tunnel VPN 2020-11-20 16:10:20 UTC

Description David Woodhouse 2018-03-09 08:51:18 UTC 
My employer requires me to run a full-tunnel VPN. This is fairly common practice; I am required to use the VPN for *all* IP traffic, as if it was the 20th century and I had dialled into the corporate modem bank.

Policy requires that I don't even have routes to my local network. Since
https://bugzilla.gnome.org/show_bug.cgi?id=767288 is not yet implemented in NM, they achieve that with a NM dispatcher script to update the routing tables.
(This is background information; this part is working OK although it would be *nice* to have it properly supported without the hackish script.)

However, NetworkManager is misconfiguring the DNS. Even when it's on a full-tunnel VPN it's still attempting to talk to the local nameservers on the physical network for some lookups. Once on the full-tunnel VPN, it should never use them at all.

This is both a functional problem, and a security problem.

It's a functional problem because some domains get *different* results when looked up internally. This split-horizon "schizo-DNS" is a heinous crime, but unfortunately common. And it's not just "company.com" which is actually in my default "append to failing queries and try this before eventually failing" search domain for the VPN, but all kinds of other subsidiary names and "company-corp.com".

I also want to get the *correct* GeoDNS results for the place my traffic is going to emerge onto the Internet, not a local GeoDNS result leads to worse routing.

It's a security problem because when I'm on a full-tunnel VPN I should *never* leak information about what I'm looking up, to potentially hostile local DNS servers. This is supposed to be like dial-up directly into the company network. That is the expectation, and to do otherwise is very wrong.
Comment 1 David Woodhouse 2018-03-09 08:58:30 UTC 
Reading that back, I'm not sure why I even mentioned the routing trick to stop access to the local network. That's just how I *noticed* this problem, of course, because those insecure attempts to reach the local network were rightly prevented.
Comment 2 David Woodhouse 2018-03-09 09:06:29 UTC 
Ubuntu used to have a patch which fixed this, but dropped it:
http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu/view/head:/debian/patches/Filter-DNS-servers-to-add-to-dnsmasq-based-on-availa.patch
Comment 3 Beniamino Galvani 2018-03-21 15:45:06 UTC 
On Fedora the default configuration is dns=default, which means that
NM updates resolv.conf directly. With this configuration, if you
connect to a full-tunnel VPN, resolv.conf will be updated to have the
VPN name server as first entry and the local name server after. This
guarantees that DNS queries go through the VPN; only when the VPN name
server is not reachable the local server is contacted. Since this can
be harmful in some situations (but there are cases when this is
useful), it is possible to set ipv4.dns-priority=-1 for the VPN so
that only the VPN name server get added to resolv.conf.

With this configuration there is no leak of DNS queries to local servers.

If you change the default configuration and set dns=dnsmasq, then NM
enables split-dns and uses the VPN name server only for the domains in
the VPN search list, even if the VPN gets the default route. This is
suboptimal and probably can be fixed introducing a new variable
(perhaps "dns.lookup-priority" ?), that indicates which connections
should be used for DNS queries not matching any lookup domain. The
default value (0, "auto"), should prioritize first full-tunnel VPNs and
then non-VPN connections. But I'll send a more detailed explanation on
the upstream bugzilla.
Comment 4 Ben Cotton 2018-11-27 16:32:03 UTC 
This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 5 Robbie Harwood 2020-01-24 20:36:36 UTC 
Hi, was this ever fixed?
Comment 6 Beniamino Galvani 2020-01-26 08:45:16 UTC 
Yes, this was fixed in NM 1.12 (Fedora 29).
Note You need to log in before you can comment on or make changes to this bug.