Gargoyle Forum

7 vulnerabilities have been disclosed regarding dnsmasq (the part of Gargoyle which provides DNS and DHCP services). Collectively these are known as DNSpooq.

The vulnerability likely affects all Gargoyle versions, with 2 of the vulnerabilities having real impact, and the remaining 5 only for users who do custom configurations to use DNSSEC features.

At this point in time, OpenWrt have not decided to backport the fixes to the 18.06 branch. This is the branch that Gargoyle 1.12.x is based on. Therefore, 1.12.x (and earlier) will not receive an update to fix this issue. It is recommended that you follow the Mitigation section below for these versions.

For 1.13.x (unreleased) or any builds based on the latest master branch of Gargoyle, a patch has been pulled in as of 26/01/2021. It is recommended that you upgrade to a new version when it becomes available, or build a new one yourself. If this is not something you are comfortable with, you can also follow the Mitigation section below.

Mitigation
If you cannot upgrade to a later version of dnsmasq, you can mitigate the vulnerability by performing the following commands:
Mitigation for DNS cache poisoning is disabling of caching: Mitigation for DNSSEC vulnerability is disabling of DNSSEC feature: It's recommended to reduce the maximum of queries allowed to be forwarded (default is 150): Then you should commit changes and restart dnsmasq:

A fixed (and then re-fixed, for a log issue) version is now out (it's nominally 2.84 but shows up in OpenWRT as 2.80-16.3).

Gargoyle uses 2.80-1.4.

Are we free to use opkg to update Gargoyle 1.12.0 to solve the issue, or is it not that simple?

Updated dnsmasq binaries will not be available for 1.12.x.
If you want to try and load them from a newer version, by all means, but compatibility/stability are not guaranteed and no support can be provided. The mitigation above is what is available at the moment.

Thanks, I hadn't seen this post.

Do you have a feel for what the disabling of caching would mean for its actual function (beyond the vulnerability)?

In theory, every DNS request gets cached (up to the limit) and those cached ones get responded to at the latency of your LAN (say 1ms wired, 30ms wireless) because we already know the answer.
For uncached (or new requests), the router forwards the request to it's upstream DNS for an answer. Let's say best case you're using a low latency DNS and the response takes another 20ms. You're maybe at a worst case, 50ms worse off than you otherwise would have been.

Will you notice that browsing? Not likely. Your network will be a little chattier than it otherwise would have been.

OK, makes sense.

While I haven't done it yet, it's worth mentioning that it's very likely to cause a bunch of these errors:

daemon.err dnsmasq[24211]: failed to send packet: Network unreachable

It happened for everyone with OpenWRT who implemented the workarounds even before the dnsmasq update, so it should happen here, too. It also happened with last week's dnsmasq update.

It's triggered by clients using IPv6 apparently, and several reported that it's more than cosmetic, actually making a noticeable impact in things like voip. In this case, the cure may be worse than the disease.

This week's dnsmasq worked around the issue.

That's why I waited and picked up the fixes to the fixes. No one should see that with Gargoyle

Yes, I was referring to what we'd see in the release version with the mitigation, not the latest dev with the updated dnsmasq.

I've been trying this mitigation approach and I'm getting two things. First off my putty session just stalls when I input the 3rd line of code:


root@Gargoyle:~# uci set dhcp.@dnsmasq[0].cachesize='0'
root@Gargoyle:~# uci set dhcp.@dnsmasq[0].dnssec='0'
root@Gargoyle:~# uci set dhcp.@dnsmasq[0].dnsforwardmax='50''
>

Second, here is what I get if I restart putty and put in the 1st, 2nd and 4th lines of code:

root@Gargoyle:~# uci set dhcp.@dnsmasq[0].cachesize='0'
root@Gargoyle:~# uci set dhcp.@dnsmasq[0].dnssec='0'
root@Gargoyle:~# uci commit dhcp && /etc/init.d/dnsmasq restart
udhcpc: started, v1.28.4
udhcpc: sending discover
udhcpc: no lease, failing
root@Gargoyle:~#

Am I doing something wrong or is this what is supposed to happen?

The first one that is "stalling" has a typo. The 50 should be surrounded by single quotes. I've fixed the typo in my post, apologies.

The messages after restart are normal and expected.