Re: [Dnsmasq-discuss] CERT Vulnerability VU#598349

2018-10-04 Thread Josh Soref
Simon Kelley  wrote:
> 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. The client sends an Autodiscover request to 
> https://autodiscover.woodgrovebank.com/autodiscover/autodiscover.xml, and 
> does one of the following:

[2] https://tools.ietf.org/html/rfc8461
>  Thus, for a Policy Domain of "example.com", the full URL is
>  "https://mta-sts.example.com/.well-known/mta-sts.txt;.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] CERT Vulnerability VU#598349

2018-09-17 Thread Simon Kelley
On 10/09/18 00:19, klondike wrote:
> Hi Simon,
> 
> El 08/09/18 a las 19:17, Simon Kelley escribió:
>> 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.




signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] CERT Vulnerability VU#598349

2018-09-09 Thread klondike
Hi Simon,

El 08/09/18 a las 19:17, Simon Kelley escribió:
> 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




signature.asc
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] CERT Vulnerability VU#598349

2018-09-09 Thread Uwe Schindler
Hey,
> > 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



___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] CERT Vulnerability VU#598349

2018-09-08 Thread James Feeney
Hey Simon

On 9/8/18 11:17 AM, Simon Kelley wrote:
> 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

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


[Dnsmasq-discuss] CERT Vulnerability VU#598349

2018-09-08 Thread 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  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.








___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss