I opened PR kern/5294 against 2.2.5R and provided a patch for this problem in December, currently the PR is 'suspended, awaiting committer'. See http://www.freebsd.org/cgi/query-pr.cgi?pr=5294 On Wed, 27 May 1998, J.A. Terranson wrote: > 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 > -- Joe Traister | He had that rare weird electricity about him -- that traisterat_private | extremely wild and heavy presence that you only see in Director of NetOps | a person who has abandoned all hope of ever behaving CyberGate, Inc. | "normally." -- Hunter S. Thompson
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:54:58 PDT