[Dnsmasq-discuss] CERT Vulnerability VU#598349

[Simon Kelley]

https://www.kb.cert.org/vuls/id/598349

The essence of this is that an attacker can get a DHCP lease whilst
claiming the name "wpad" and thus insert the name wpad.example.com in
the local DNS pointing the attacker's machine. The presence of that A
record allows control of the proxy settings of any browser in the network.

It's already possible to mitigate this: adding

0.0.0.0 wpad wpad.example.com
:: wpad.wpad.example.com

to /etc/hosts will generate harmless A and AAAA records which override
those that may be created by DHCP leases.


The currently unreleased 2.80 version of dnsmasq adds the
dhcp-name-match option, which allows

dhcp-name-match=set:wpad-ignore,wpad
dhcp-ignore-names=tag:wpad-ignore

Which stops the attack at source.


The question is, should the above configuration be "baked in" to the code?



Cheers,

Simon.

[James Feeney]

Hey Simon

Post by Simon Kelley
The question is, should the above configuration be "baked in" to the code?

As I understand, this vulnerability arises from the Web Proxy Automatic Discovery (WPAD) protocol, not from dnsmasq itself. And, dnsmasq configuration provides - or will provide - a configuration mechanism to obviate the shortcomings of the WPAD protocol. My inclination would be to *not* change the code, on the off-chance that someone might consider this specific function of the WPAD protocol to be a "feature", and instead, to rely upon the proper dnsmasq configuration, which would make overt to the network administrator just how the "wpad" sub-domain is being handled. And then, for instance, as you say,
dhcp-name-match=set:wpad-ignore,wpad
dhcp-ignore-names=tag:wpad-ignore
could be recommended in the default dnsmasq configuration file.

Also, the CERT note says "Other autodiscovery names, such as, ISATAP, autodiscovery and autoconf may also be exploitable." And dnsmasq could be playing "wack-a-mole" with sub-domain names in the code, if handled that way. It's easier to play "wack-a-mole" from the configuration file.

My first thoughts...

James

[Uwe Schindler]

Hey,

Post by James Feeney

Post by Simon Kelley
The question is, should the above configuration be "baked in" to the code?

As I understand, this vulnerability arises from the Web Proxy Automatic
Discovery (WPAD) protocol, not from dnsmasq itself. And, dnsmasq
configuration provides - or will provide - a configuration mechanism to
obviate the shortcomings of the WPAD protocol. My inclination would be to
*not* change the code, on the off-chance that someone might consider this
specific function of the WPAD protocol to be a "feature", and instead, to rely
upon the proper dnsmasq configuration, which would make overt to the
network administrator just how the "wpad" sub-domain is being handled.
And then, for instance, as you say,
dhcp-name-match=set:wpad-ignore,wpad
dhcp-ignore-names=tag:wpad-ignore
could be recommended in the default dnsmasq configuration file.
Also, the CERT note says "Other autodiscovery names, such as, ISATAP,
autodiscovery and autoconf may also be exploitable." And dnsmasq could
be playing "wack-a-mole" with sub-domain names in the code, if handled
that way. It's easier to play "wack-a-mole" from the configuration file.

I fully agree with this. IMHO, the new 2.80 config settings for name matches to ignore should maybe added to default config.

dhcp-name-match=set:wpad-ignore,wpad
dhcp-ignore-names=tag:wpad-ignore

By the way, I'd also like to "ignore" the name "localhost", as exposed by Samsung SmartTVs. This is annoying, as it registers "localhost" as a domain name. It should just ignore that hostname, if provided by the DHCP client. If the above option helps to provide this "ignores", then we can add more hostnames like this that cannot be taken by DHCP clients.

Uwe

[klondike]

Hi Simon,

Post by Simon Kelley
The question is, should the above configuration be "baked in" to the code?

Yes. In general it is considered against good practice to provide insane
defaults and in this case this entails software and not configuration
defaults.

Keep in mind that dnsmasq is used by a wide variety of users nowadays,
not only home routers and embedded  but also as a simple DHCP/DNS server
in NAT setups, for example by NetworkManager or libvirt. Getting all of
these users to update the way in which they generate dnsmasq
configurations may be impractical as oposed to the rare case of allowing
the names in such a blacklist.

Because of this it would be best to let dnsmasq to default to safe
behaviour (filtering known bad names like wpad) and allowing users to
disable this behaviour via a configuration/command line directive. That
way the next update will fix the problem for the majority of users out
of the box whilst still allowing the few with a legitimate interest in
allowing overriding of entries like wpad to do so.

If you need help writting such a patch I can try to get some time to do so.

Sincerely,

Klondike

[Simon Kelley]

Post by klondike
Hi Simon,

Post by Simon Kelley
The question is, should the above configuration be "baked in" to the code?

Yes. In general it is considered against good practice to provide insane
defaults and in this case this entails software and not configuration
defaults.
Keep in mind that dnsmasq is used by a wide variety of users nowadays,
not only home routers and embedded  but also as a simple DHCP/DNS server
in NAT setups, for example by NetworkManager or libvirt. Getting all of
these users to update the way in which they generate dnsmasq
configurations may be impractical as oposed to the rare case of allowing
the names in such a blacklist.
Because of this it would be best to let dnsmasq to default to safe
behaviour (filtering known bad names like wpad) and allowing users to
disable this behaviour via a configuration/command line directive. That
way the next update will fix the problem for the majority of users out
of the box whilst still allowing the few with a legitimate interest in
allowing overriding of entries like wpad to do so.
If you need help writting such a patch I can try to get some time to do so.
Sincerely,
Klondike

So, if I read the replies so far correctly, we have votes both for
"ignore wpad by default, and give an option to switch that off" and
"don't ignore wpad by default, but add the code to do so to the example
config file."

The first is a bit of a problem, if you have

dhcp-name-match=set:wpad-ignore,wpad
dhcp-ignore-names=tag:wpad-ignore

either in a global config file, or baked into the code.

there's no way to unset the wpad-ignore tag, or override the
dhcp-ignore-names directive.

The second is easier to achieve, but the example config file is a little
unloved these days. I kind of lost the habit of adding each new
configuration option in there.


Cheers,


Simon.

[Josh Soref]

Post by Simon Kelley
So, if I read the replies so far correctly, we have votes both for
"ignore wpad by default, and give an option to switch that off" and
"don't ignore wpad by default, but add the code to do so to the example
config file."
The first is a bit of a problem, if you have
dhcp-name-match=set:wpad-ignore,wpad
dhcp-ignore-names=tag:wpad-ignore
either in a global config file, or baked into the code.
there's no way to unset the wpad-ignore tag, or override the
dhcp-ignore-names directive.

Sounds like this isn't the right way to define a configuration.
Since being able to override it seems important.

I'd argue in favor of baking in a number of these things...

Offhand,
"autodiscover" [1]

Probably "www" and "ftp", possibly "ns", and probably "mta-sts" [2].

As for examples, I suppose the next time I revisit dnsmasq, I might
look into the examples problem, currently I'm fighting yaks in pdns
land (which is where I learned about the mta-sts thing, which is
really awful, but, hey).

[1] https://blogs.msdn.microsoft.com/exchangedev/2011/07/07/autodiscover-for-exchange-activesync-developers/
[2] https://tools.ietf.org/html/rfc8461

Post by Simon Kelley
Thus, for a Policy Domain of "example.com", the full URL is
"https://mta-sts.example.com/.well-known/mta-sts.txt".