[Dnsmasq-discuss] Announce 2.85rc1 and security warning.
simon at thekelleys.org.uk
Wed Mar 17 21:48:02 UTC 2021
I've just created the first release candidate for dnsmasq-2.85.
Since 2.84 this has a couple of stand-alone configuration enhancements,
a fix for DNS retries which addresses a regression in 2.84, and a large
fix which address a historic error.
Way back, when Dan Kaminsky revealed the birthday attack, dnsmasq was
taught to use random source ports to talk to upstream servers. Some
flaws in that code were the subject of some of the last security fixes
in 2.83 and 2.84.
At the time, dnsmasq could already be configured to set some or all of
the source address, source port and physical interface it used to
communicate with upstream servers. This is done with configuration
server=184.108.40.206 at eth0
server=220.127.116.11 at 18.104.22.168
server=22.214.171.124 at 126.96.36.199#100
The way the code worked was that at start up, the relevant sockets were
created and bound. If that failed, dnsmasq refused to run, so the error
had to be fixed if a non-existent interface or a source address which
didn't exist on the host was specified.
The new code to do random source ports didn't trample on any of this. If
the source was configured, it left things alone. Any server configured
without the @...... got random source ports.
All was good. Then at some point, networkmanager, the GUI network config
system which makes Linux desktops and laptops easy to configure, started
collecting upstream DNS servers from all it's upstream connections, and
configuring dnsmasq as a DNS forwarder to use those upstream resolvers.
If it got an upstream resolver 188.8.131.52 via, say, DHCP on eth0 it would
tell dnsmasq about it, and tell dnsmasq to talk via eth0 when it talked
server=184.108.40.206 at eth0
Nobody realised that now, dnsmasq was talking to 220.127.116.11 alright, but it
was creating a single socket to do it, with a single random, but
unchanging port. The random source port behavior was disabled, making
cache poisoning attacks possible.
Apart from making bind errors a run-time rather than a start-time error,
there's no need for this: as long as the source _port_ is not nailed
down, there's nothing to stop dnsmasq making a new socket for each
transaction, with a random port, and binding to an interface (or
address). Very few people configured the source for upstream servers,
but networkmanager does, and lots of people use networkManager, so this
is widespread problem.
The 2.85 release fixes this. Unless the source port to talk to an
upstream server is explicitly set with
server=18.104.22.168 at 22.214.171.124#100
then random source ports will always be used.
There's no problem unless you use
server=126.96.36.199 at eth0 or server=188.8.131.52 at 184.108.40.206
(or their DBus equivalents)
OR if you use NetWorkManager with dnsmasq.
In that case, upgrading to 2.85 is advised.
CVE-2021-3448 is the formal designation for this bug.
Thanks to Petr Menšík for finally spotting this historic oversight, and
good work on fixing it.
and test it thoroughly. Then look at the diff at
and pity the people who are going to have to backport this.
More information about the Dnsmasq-discuss