Bug 1553634

Summary:	CVE-2018-1000135 Full-tunnel VPN misconfigures DNS servers, leaks private information
Product:	[Fedora] Fedora	Reporter:	David Woodhouse <dwmw2>
Component:	NetworkManager	Assignee:	Lubomir Rintel <lkundrak>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	27	CC:	alexl, bgalvani, dcbw, fgiudici, john.j5live, lkundrak, mclasen, rharwood, rhughes, sandmann, thaller
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-01-26 08:45:16 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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).