FreeBSD 2.2.5R - FreeBSD Current "SMURF" Vulnerability (fwd)
Peter Czanik
pczanik at fang.fa.gau.hu
1998. Május. 27., Sze, 22:19:30 CEST
Hello,
Ha valaki esetleg nincs fenn a bugtraq-on... Bye,
Peter Czanik GAU Faculty of Agriculture
pczanik at fang.fa.gau.hu http://fang.fa.gau.hu/~pczanik/
Favorite link: http://www.szoborpark.hu/
S.u.S.E. Support database: http://www.integrity.hu/support-db/
---------- Forwarded message ----------
Date: Wed, 27 May 1998 11:37:39 -0500
From: "J.A. Terranson" <sysadmin at MFN.ORG>
To: BUGTRAQ at NETSPACE.ORG
Subject: FreeBSD 2.2.5R - FreeBSD Current "SMURF" Vulnerability
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 [sysadmin at mfn.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 [andrew at squiz.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 [sysadmin at mfn.org])
I am running fairly plain-jane FBSD 2.2.5 from FTP.FREEBSD.ORG...
CERT is *wrong*
(5/27/98-0150 Andrew McNaughton [andrew at squiz.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 [sysadmin at mfn.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 [bag at sinbin.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 [bit at signature.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 [sthaugh at nethelp.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 [benedict at echonyc.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 [dg at root.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 [dg at root.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
További információk a(z) BSD levelezőlistáról