Hi,
playing with my linux box I experienced a problem with ICMP hardware
broadcasts. It seems that kernel responds to each multicast/broadcast
timestamp/echo query it receive, and there is no possibility to control that.
simple proof-of-concept:
192.168.3.2 - linux-2.6.12.1, ipv4
Sch0mikS:/# screen -d -m tcpdump -q -e -t -n 'src 192.168.3.2 and
icmp[0] == 14 and broadcast'
Sch0mikS:/# sing -tstamp -c 1 -MAC FF:FF:FF:FF:FF:FF 192.168.3.2
SINGing to 192.168.3.2 (192.168.3.2): 20 data bytes
20 bytes from 192.168.3.2: seq=0 ttl=65 TOS=0 diff=56262
--- 192.168.3.2 sing statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
Sch0mikS:/# screen -r
00:10:a7:20:17:dc > ff:ff:ff:ff:ff:ff, IPv4, length 60: IP 192.168.3.2 >
192.168.3.1: icmp 20: time stamp reply id 10247 seq 0 : org 0x2333ee7
recv 0x2341aad xmit 0x2341aad
Refer to security policy, shouldn't the ICMP broadcast packet
be dropped right after it appear in icmp_rcv()?
quickfix:
--- linux-2.6.12.1/net/ipv4/icmp.c 2005-06-29 14:05:23.000000000 +0200
+++ linux/net/ipv4/icmp.c 2005-06-29 21:16:08.000000000 +0200
@@ -950,6 +950,16 @@
icmph = skb->h.icmph;
/*
+ * Discard physical multicast/broadcast except ICMP_ECHO
+ * if allowed
+ */
+ if ((skb->pkt_type != PACKET_HOST) && (icmph->type != ICMP_ECHO))
+ goto error;
+ if ((skb->pkt_type != PACKET_HOST) && (icmph->type == ICMP_ECHO) &&
+ (sysctl_icmp_echo_ignore_broadcasts))
+ goto error;
+
+ /*
* 18 is the highest 'known' ICMP type. Anything else is a mystery
*
* RFC 1122: 3.2.2 Unknown ICMP messages types MUST be silently
@@ -970,8 +980,9 @@
* RFC 1122: 3.2.2.8 An ICMP_TIMESTAMP MAY be silently
* discarded if to broadcast/multicast.
*/
- if (icmph->type == ICMP_ECHO &&
- sysctl_icmp_echo_ignore_broadcasts) {
+ if ((icmph->type == ICMP_ECHO &&
+ sysctl_icmp_echo_ignore_broadcasts) ||
+ (icmph->type == ICMP_TIMESTAMP)) {
goto error;
}
if (icmph->type != ICMP_ECHO &&
--
Tomasz Chomiuk .:ch0mik[at]hotpop.com
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
