Here's the entire thread, from discovery to patch (you just gotta love it when you can go from A to B in less than 24 hours!!!). I found the comment by "Snob Art Genre" to be a perfect example of finding the good in *everything* :) (5/26/98-2206 J.A. Terranson [sysadminat_private]) FBSD (2.2.5R) machines will always respond to a broadcasted echo request. For example: W2>ping 10.1.1.255 PING 10.1.1.255 (10.1.1.255): 56 data bytes 64 bytes from 10.1.1.20: icmp_seq=1 ttl=255 time=4.746 ms 64 bytes from 10.1.1.23: icmp_seq=1 ttl=255 time=45.864 ms (DUP!) lots of these dups... In fact, 1 dup for every FBSD machine on the subnet (5/27/98-0038 Andrew McNaughton [andrewat_private]) This contradicts the CERT Advisory below which states that FreeBSD does not have the problem. Either the CERT report is wrong, a problem has been introduced since, or it's specific to the way you've set up your boxes. <snip> <CERT Advisory CA-98.01.smurf attached> (5/27/98-0057 J.A. Terranson [sysadminat_private]) I am running fairly plain-jane FBSD 2.2.5 from FTP.FREEBSD.ORG... CERT is *wrong* (5/27/98-0150 Andrew McNaughton [andrewat_private]) Now confirmed here also pining from my mac, which has the same problem. CERT and BugTRAQ should be notified. Not sure if this should wait for a patch to be issued. (5/27/98-0217 J.A. Terranson [sysadminat_private]) I assume you guys have been following the thread... I will not report this to bugtraq untill you guys tell me there's a patch... (5/27/98-0248 Alex G. Bulushev [bagat_private]) CERT report is wrong i check -current (Apr 23) and found that it respond to broadcast ping, default net.inet.icmp.bmcastecho=1, but it alsow respond to broadcast after sysctl -w net.inet.icmp.bmcastecho=0 the good news is that in both case it not respond from aliases :) (5/27/98-0350 Bart Smit [bitat_private]) Well, sysctl -w net.inet.icmp.bmcastecho=0 does not help, contrary to what you'd expect from the advisory... (5/27/98-0540 Steinar Haug [sthaughat_private]) The problematic code is the following, from the icmp_input() routine in sys/netinet/ip_icmp.c: <snip> I found it just as logical to simply remove the whole test, but I'll let somebody else decide on whether this is the correct fix. I also changed the initialization of the icmpbmcastecho variable, so it now defaults to off (no multicast/broadcast echo). The following patch is against 2.2-980506-SNAP (ip_icmp.c,v 1.22.2.2), but should work equally well against FreeBSD-current. Late breaking news: I just checked -current on ftp.cdrom.com, and it now has the IN_MULTICAST test removed. Still initializes icmpbmcastecho to 1, though. I think it *should* default to 0 (off). (5/27/98-1021 Snob Art Genre [benedictat_private]) > W2>ping 10.1.1.255 > PING 10.1.1.255 (10.1.1.255): 56 data bytes > 64 bytes from 10.1.1.20: icmp_seq=1 ttl=255 time=4.746 ms > 64 bytes from 10.1.1.23: icmp_seq=1 ttl=255 time=45.864 ms (DUP!) > lots of these dups... I've always found this useful, for when I want to build a complete ARP cache for the local network. I use it with NeXTStep all the time. Perhaps the behavior should be modified to respond to broadcast pings iff they're from a directly connected network, otherwise ignore? (5/27/98-1021 David Greenman [dgat_private]) >Well, sysctl -w net.inet.icmp.bmcastecho=0 does not help, contrary to >what you'd expect from the advisory... That's because the logic for it was broken in the kernel. I just fixed it yesterday. Diff attached (line numbers in -stable will vary slightly). -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project Index: ip_icmp.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_icmp.c,v retrieving revision 1.29 retrieving revision 1.30 diff -c -r1.29 -r1.30 *** ip_icmp.c 1997/08/25 16:29:27 1.29 --- ip_icmp.c 1998/05/26 11:34:30 1.30 *************** *** 375,382 **** case ICMP_ECHO: if (!icmpbmcastecho ! && (m->m_flags & (M_MCAST | M_BCAST)) != 0 ! && IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) { icmpstat.icps_bmcastecho++; break; } --- 375,381 ---- case ICMP_ECHO: if (!icmpbmcastecho ! && (m->m_flags & (M_MCAST | M_BCAST)) != 0) { icmpstat.icps_bmcastecho++; break; } *************** *** 385,392 **** case ICMP_TSTAMP: if (!icmpbmcastecho ! && (m->m_flags & (M_MCAST | M_BCAST)) != 0 ! && IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) { icmpstat.icps_bmcasttstamp++; break; } --- 384,390 ---- case ICMP_TSTAMP: if (!icmpbmcastecho ! && (m->m_flags & (M_MCAST | M_BCAST)) != 0) { icmpstat.icps_bmcasttstamp++; break; } (5/27/98-1025 David Greenman [dgat_private]) >Late breaking news: I just checked -current on ftp.cdrom.com, and it >now has the IN_MULTICAST test removed. Still initializes icmpbmcastecho >to 1, though. I think it *should* default to 0 (off). I noticed the bug last week when cdrom.com was the target of a smurf attack. It took a few days to get Garrett's opinion on how to fix it, and I committed the fix yesterday. -DG
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:54:41 PDT