[Dnsmasq-discuss] Announce 2.85rc1 and security warning.

[Simon Kelley]

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
options like

server=8.8.8.8 at eth0
server=8.8.8.8 at 1.2.3.4
server=8.8.8.8 at 1.2.3.4#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 1.1.1.1 via, say, DHCP on eth0 it would
tell dnsmasq about it, and tell dnsmasq to talk via eth0 when it talked
to 1.1.1.1

server=1.1.1.1 at eth0

Nobody realised that now, dnsmasq was talking to 1.1.1.1 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=8.8.8.8 at 1.2.3.4#100

or

query-port=100

then random source ports will always be used.


TL;DR

There's no problem unless you use

server=8.8.8.8 at eth0 or server=8.8.8.8 at 1.2.3.4

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

Please download

https://thekelleys.org.uk/dnsmasq/release-candidates/dnsmasq-2.85rc1.tar.gz

and test it thoroughly. Then look at the diff at

https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=74d4fcd756a85bc1823232ea74334f7ccfb9d5d2;hp=4c30e9602bcf272863abb6f25b04ad035ab1a27b

and pity the people who are going to have to backport this.


Cheers,

Simon.