Security Advisory 2020-12-09-1 - SAD DNS - Linux kernel - ICMP rate limiting can be used to facilitate DNS poisoning attack (CVE-2020-25705)

Release and security announcements
1

A flaw has been found in the Linux kernel that can make it easier to perform DNS cache poisoning attacks.

OpenWrt is affected in its default configuration, although it is not trivial to actually exploit. The new releases OpenWrt 18.06.9 and OpenWrt 19.07.5 fix the issue: upgrading is highly recommended.

It you cannot upgrade, there is a mitigation: in the firewall configuration, change the input policy of the WAN firewall zone from REJECT to DROP and reload the firewall configuration. This will prevent sending ICMP errors to hosts on the Internet and suppress the attack vector. Note: you don't need to do this if you have already upgraded to a fixed version of OpenWrt.

Full advisory: https://openwrt.org/advisory/2020-12-09-1

7 Likes
2

Isn't this what Steve Gibson has recommended for years? Don't let attackers know you exist by rejecting, simply drop?

1 Like
3

There are arguments for and against that. See: http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject

2 Likes
4

This issue is just one of many related to unencrypted DNS traffic.
To solve the root cause requires to enable DNS encryption:
https://openwrt.org/docs/guide-user/services/dns/start#encryption

3 Likes
5

Hostile users

Now let's consider hostile forces:

A common reason for using DROP rather than REJECT is to avoid giving away information about which ports are open, however, discarding packets gives away exactly as much information as the rejection.

With REJECT, you do your scan and categorise the results into "connection established" and "connection rejected".

With DROP, you categorise the results into "connection established" and "connection timed out".

Thanks for the link! Given a machine on an IP is offering no services at all, why should there be "connection established" assumed when there is no answer from that machine at all aka DROP? I would assume that there is no machine at all.

1 Like
6

He's talking about open port vs closed port behavior when scanning ports. So open port = connection established (let's say it's TCP), closed port = connection timed out (nothing responded back, no services offered on that port). Where REJECT would have the host send back a ICMP message saying the destination port is unreachable so: connection rejected.

2 Likes
7

That is a good link. Thank you for the explanation!

1 Like
8

Ok, but as I wrote for a machine which is offering no services a drop will pretend that you don't even exist versus a reject reveals your existence.

9

And DROP makes the attacks slower.

3 Likes
10

Someone interested in that kind of behavior should not forget to disable ICMP ECHO REPLY

1 Like
11

This fix only applies to icmp packets send from the OpenWRT device itseld, or?
How to add this random noise to forwarded ICMP packets?

Something like this ?

-m statistic --mode random --probability 0.7 -m hashlimit --hashlimit-mode srcip --hashlimit-upto 60/min --hashlimit-burst 50 --hashlimit-name WAN_FORWARD_ICMPv6

//edit
hmm
i think two rules/chains are needed.
one that matches against the rate limiter (but with hashlimit-above statement) and then hand those packets over to another chains that does the probability drop?