Prior to this commit, the ARP implementation accepted ARP req/replies with multicast (including broadcast) and null MAC addresses as Sender HW Address (SHA), and updated the ARP cache for that neighbour. Broadcast, multicast and null MAC addresses shall never be associated with a unicast or a multicast IPv4 address (see RFC1812, section 3.3.2). ARP poisioning with a broadcast MAC address and certain multicast addresses, especially when poisoning a Gateway IP, have some undesired implications compared to an ARP poisioning with a regular MAC (see Note1). Worth mentioning that if an attacker is able to ARP poison in a L2 segment, that in itself is probably a bigger security threat (Man-in-middle etc., see Note2). However, since these MACs should never be announced as SHA, discard/drop ARPs with SHA={b/mcast, null}, which prevents the broadcast/multicast ARP poisoning vector. Note1: After a successful broadcast/multicast ARP poisioning attack: 1. Unicast packets and refresh ("targeted") ARPs sent to or via the poisioned IP (e.g. the default GW) are flooded by bridges/switches. That is in absence of other security controls. Hardware swiches generally have rate-limits to prevent/mitigate broadcast storms, since ARPs are usually answered by the CPU. Legit unicast packets could be dropped (perf. degradation). Most modern NICs implement some form of L2 MAC filtering to early discard irrelevant packets. In contrast to an ARP poisoning attack with any other MAC, both unicast and ARP ("targeted") refresh packets are passed up to the Kernel networking stack (for all hosts in the L2 segment). 2. A single forged ARP packet (e.g. for the Gateway IP) can produce up to N "targeted" (to broadcast) ARPs, where N is the number of hosts in the L2 segment that have an ARP entry for that IP (e.g. GW), and some more traffic, since the real host will answer to targeted refresh ARPs with their (real) reply. This is a relatively low amount of traffic compared to 1). 3. An attacker could use this form of ARP poisoning to discover all hosts in a L2 segment in a very short period of time with one or few packets. By poisoning e.g. the default GW (likely multiple times, to avoid races with real gARPs from the GW), all hosts will eventually issue refresh "targeted" ARPs for the GW IP with the broadcast MAC address as destination. These packets will be flooded in the L2 segment, revealing the presence of hosts to the attacker. For comparison: * Passive ARP monitoring: also stealthy, but can take a long time or not be possible at all in switches, as most refresh ARPs are targeted. * ARP req flooding: requires swiping the entire subnet. Noisy and easy to detect. * ICMP/L4 port scans: similar to the above. 4. In the unlikely case that hosts were to run with `/proc/sys/net/ipv4/conf/*/arp_accept=1` (unsafe, and disabled by default), poisoning with the broadcast MAC could be used to create significantly more broadcast traffic (low-volume amplification attack). An attacker could send M fake gARP with a number of IP addresses, where M is `/proc/sys/net/ipv4/neigh/*/gc_thresh3` (1024 by default). This would result in M x R ARPs, where R is the number of hosts in L2 segment with `arp_accept=1`, and likely other (real) ARP replies coming from the attacked host. This starts to get really relevant when R > 512, which is possible in large LANs but not very common. Note2: However, broadcast ARP poisoning might be subtle and difficult to spot. These ARP packets appear on the surface as regular broadcast ARP requests (unless ARP hdr is inspected), traffic continues to flow uninterrupted (unless broadcast rate-limit in switches kick-in) and, the next refresh ARP reply (from the GW) or any (valid) gARP from the GW, will restore the original MAC in the ARP table, making the traffic flow normally again. Signed-off-by: Marc Suñé --- net/ipv4/arp.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c index c8c3e1713c0e..7dbb3fd5cc8a 100644 --- a/net/ipv4/arp.c +++ b/net/ipv4/arp.c @@ -800,6 +800,14 @@ static int arp_process(struct net *net, struct sock *sk, struct sk_buff *skb) goto out_free_skb; /* + * For Ethernet devices, Multicast/Broadcast and zero MAC addresses should + * never be announced and accepted as sender HW address (RFC1812, 3.3.2). + * Prevents Broadcast/Mcast ARP poisoning attack. + */ + if (dev->type == ARPHRD_ETHER && !is_valid_ether_addr(sha)) + goto out_free_skb; + + /* * Special case: We must set Frame Relay source Q.922 address */ if (dev_type == ARPHRD_DLCI) -- 2.47.3