As best as I recall, cerowrt enabled wpad for itself and thus was immune to this bug.
Still... do upgrade off of cerowrt if you haven't already? Simon Kelley <si...@thekelleys.org.uk> writes: > 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. > > > > > > > > > _______________________________________________ > Dnsmasq-discuss mailing list > dnsmasq-disc...@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
