Security Advisory 2021-01-19-1 - dnsmasq multiple vulnerabilities

[ynezz]

Multiple flaws (7 CVEs) has been found in the dnsmasq package. Dnsmasq has two sets of vulnerabilities, one set of memory corruption issues handling DNSSEC and a second set of issues validating DNS responses. These vulnerabilities could allow an attacker to corrupt memory which can lead to denial of service, information exposure and potentially remote code execution on the target device. The DNS response validation vulnerabilities allow an attacker to use unsolicited DNS responses to poison the DNS cache resulting in redirection of users to malicious sites.

These vulnerabilities are also referred to as DNSpooq and there is full security advisory available as well.

1. Configuration based mitigation via LuCI web interface

• Max. concurrent queries is dnsforwardmax, so set it to recommended value of 50
• Size of DNS query cache is cachesize, so disable the caching by setting it to value of 0
• DNSSEC is dnssec, so you need to disable it if enabled and available

2. Configuration based mitigation via commandline

• Mitigation for DNS cache poisoning is disabling of caching:

  uci set dhcp.@dnsmasq[0].cachesize='0'

• Mitigation for DNSSEC vulnerability is disabling of DNSSEC feature:

  uci set dhcp.@dnsmasq[0].dnssec='0'

• It's recommended to reduce the maximum of queries allowed to be forwarded (default is 150):

  uci set dhcp.@dnsmasq[0].dnsforwardmax='50'

• Then you should commit changes and restart dnsmasq:

  uci commit dhcp && /etc/init.d/dnsmasq restart

3. Package upgrade to fixed dnsmasq version

• You need to update the affected dnsmasq package variant you're using with the
  command below.

  opkg update; opkg upgrade $(opkg list-installed dnsmasq* | cut -d' ' -f1)

• Then verify, that you're running fixed version.

  opkg list-installed dnsmasq*

The above command should output following:

• dnsmasq - 2.80-16.2 for stable 19.07 release
• dnsmasq - 2.83-1 for master/snapshot

[jc1685]

This package upgrade process doesn't work for my Linksys RE6500 running 19.07.5. It doesn't have an updated dnsmasq file after the process, at least for the time being. It still reports version 2.80-16.1. Worked fine on WRT1900AC v1.

[TopDog]

Will there be an updated package for the 18.06 tree?

I have a fleet deployed and can't move to 19.07 yet.

[hauke]

Currently there is no update to fix this problem for the 18.06 release branch planned.
We did the last release in the 18.06 branch in December 2020 and communicated that we are not planning to do any 18.06.10 release.

[otnert]

Anyone else getting this system log error?
It's taking over the log.

Wed Jan 20 11:01:12 2021 daemon.err dnsmasq[7174]: failed to send packet: Address family not supported by protocol
Wed Jan 20 11:01:12 2021 daemon.err dnsmasq[7174]: failed to send packet: Address family not supported by protocol
Wed Jan 20 11:01:13 2021 daemon.err dnsmasq[7174]: failed to send packet: Address family not supported by protocol
Wed Jan 20 11:01:13 2021 daemon.err dnsmasq[7174]: failed to send packet: Address family not supported by protocol

Restarted dhcp & network, still the same.

Now this also:

Wed Jan 20 11:08:30 2021 daemon.err dnsmasq[7174]: failed to send packet: Network unreachable

[takimata]

@otnert

Anyone else getting this system log error?

Can confirm, I get a crapton of daemon.err dnsmasq[...]: failed to send packet: Network unreachable errors. They appear to come in bursts, and they clutter up the syslog, but they seem to be benign.

[otnert]

Glad it's not only me getting these...

Is there a way to suppress these errors as they're overrunning the system log!

[vgmz95]

I'm seeing the same dnsmasq error. I haven't install any additional packages.

[rseiler]

Are the last four posters talking about 19.07.5 plus the manual workarounds described by OP (this is what I assume) or is that log issue in 19.07.6, too?

[openwrtforever]

I upgraded to 19.07.6 and I am also seeing this error on my WRT3200ACM, I hope someone would be able to find the cause.

[wterlave89]

I'm not seeing that system log problem in 19.07.6 on my R7800.

[Limentinus]

I understand the intent to not update the 18.06 release - you have to stop support sometime.

However, like others, I manage a small fleet of OpenWrt routers, and the COVID-19 travel restrictions make it unreasonably difficult to travel to the countries I need to in order to do an on-site upgrade. I would normally upgrade the routers remotely, but the transition from 18.06 to 19.07 is a 'breaking upgrade' for me, as the hardware moves from ar71xx to ath79 and the recommended upgrade process is to do a sysupgrade without keeping settings. The default settings, obviously, do not allow remote login...

So, I would be happy if 18.06 could be supported until travel is easier.

Alternatively, as the devices are connected by the WAN Ethernet (eth0), I can cope if all I need to do is delete the WiFi config before upgrade and recreate it after. The extra work is trivial compared to needing to travel to each remote site. I do not have anyone capable of technical support at the remote sites.

The Ethernet switch is Atheros AR8327N (devices are TP-Link Archer C7 v2)

If that is not possible, then would installing dnsmasq via opkg install the newly patched version on 18.06?

Limentinus

[wterlave89]

@Limentinus

I would normally upgrade the routers remotely, but the transition from 18.06 to 19.07 is a 'breaking upgrade' for me, as the hardware moves from ar71xx to ath79 and the recommended upgrade process is to do a sysupgrade without keeping settings. The default settings, obviously, do not allow remote login...

There are also ar71xx builds of 19.07. You could install those.

19.07 introduced the ath79 target, and it is the more modern, preferred option, but many devices have both ath79 and ar71xx builds available.

However, the next major release AFTER the 19.07.x series will not have ar71xx builds available. In other words, 21.xx, whenever that comes out. Also, if the devs follow the usual pattern, there will still be a handful of minor 19.07.x updates after the 21.xx series comes out.

So you should be able to update from 18.06.x ar71xx to 19.07.6 ar71xx (which includes the relevant dnsmasq security patches), and just use them that way for now. Then by the time 19.07.x becomes unsupported, you will hopefully by then have already gotten vaccinated and started travelling to those countries to install ath79 firmware.

---

In the event that you are not able to be vaccinated by then, I can think of two possible options you would likely still have:

1. You could temporarily hire technical people in those countries to assist you OR, barring that…
2. If you're not able to find someone technical in those countries, you could purchase identical router models, have them shipped where you are, install ath79 builds on them and configure settings as you like, and then ship them to non-technical people in those countries. Make it so that the only thing they have to do is disconnect all the cables from the old routers and plug them into the new routers instead. Make it a drop in replacement (just don't forget things like WAN MAC address cloning, if needed for those ISPs). If it makes you feel better, you could use video chat with them to ensure that they swap all the cables over correctly.

Again, those last two options are just some contingency plans in case you aren't able to get vaccinated and travel by the time 19.07.x becomes unsupported. You've probably got the better part of this year to figure this out and prepare. In the meantime, just go ahead and install those 19.07.6 ar71xx builds like I said.

[otnert]

Using 19.07.5, now 19.07.6, pre & post manual workarounds described by OP

[Limentinus]

Thank you for the link to the ar71xx builds. I either didn't know of, or had forgotten about their existence. I will do some testing.

I do want to move to the ath79 builds: I did think of creating an image I could copy across from USB so I could send out USB sticks and flash a new image. Asking people to plug in a USB stick is OK, asking them to log in and configure stuff isn't. (In actual fact, getting local people to buy a USB stick and plug in, so I can download the image is workable too, so I don't even have to send USB sticks by post.)

Hiring technical people is cost-prohibitive. I can do upgrades incidental to scheduled trips for other purposes. I suspect when the time comes for hardware replacement, I will look for hardware that allows two images on two partitions, so fallback to a previously working image is easy.

L

[wterlave89]

Ah, good point about the USB stick approach! I should have thought of that. That definitely makes more sense than either of the two contingency plans I gave.

[smoltron]

@otnert

Anyone else getting this system log error?
It's taking over the log.

Yes, the log is now full of these errors.

[94121-usr]

I'm getting these messages, running dnsmasq - 2.83-1, r15553, on a RPi4:
daemon.err dnsmasq[564]: failed to send packet: Network unreachable
daemon.err dnsmasq[3700]: failed to send packet: Address family not supported by protocol

But overnight, I shut off my Win10 desktop, and no more errors in the system log, until I turned it back on. My Android and Debian devices remained on overnight. Hmm.....

[JonFo]

@hauke

Currently there is no update to fix this problem for the 18.06 release branch planned.

Thanks for clarifying, but given the severity of this issue, I hope that is revisited to allow the package system to be used to update dnsmasq to a safer version.

Also, I will also note huge amounts of log spam daemon.err dnsmasq[4204]: failed to send packet: Network unreachable
Using a 19.07.4 - based build, I used the opkg update method, and am now running dnsmasq - 2.80-16.2