OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Bugtraq archives for 2nd quarter (Apr-Jun) 1998: FreeBSD 2.2.5R - FreeBSD Current "SMURF" Vulnerability

FreeBSD 2.2.5R - FreeBSD Current "SMURF" Vulnerability

J.A. Terranson (sysadminMFN.ORG)
Wed, 27 May 1998 11:37:39 -0500

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 [sysadminmfn.org])
        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 [andrewsquiz.co.nz])
        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 [sysadminmfn.org])
        I am running fairly plain-jane FBSD 2.2.5 from FTP.FREEBSD.ORG...
        CERT is *wrong*

(5/27/98-0150 Andrew McNaughton [andrewsquiz.co.nz])
        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 [sysadminmfn.org])
        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 [bagsinbin.demos.su])
        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 [bitsignature.nl])
        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 [sthaughnethelp.no])

        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 [benedictechonyc.com])
        > 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 [dgroot.com])
>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 [dgroot.com])
>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