-----BEGIN PGP SIGNED MESSAGE----- =============================================================================== Security Advisory CERT-NL =============================================================================== Author/Source : Teun Nijssen Index : S-98-37 Distribution : World Page : 1 Classification: External Version: 1 Subject : FreeBSD smurf attacks Date : 10-Jun-98 =============================================================================== By courtesy of FreeBSD Inc. we received the following information about smurf attacks. Note that CERT-NL advisory S-98-01 already handled the generic smurf attack. CERT-NL advises to apply the included source code patch to the relevant FreeBSD systems. ============================================================================= FreeBSD-SA-98:06 Security Advisory FreeBSD, Inc. Topic: smurf attack Category: core Module: kernel Announced: 1998-06-10 Affects: FreeBSD 2.2.*, FreeBSD-stable and FreeBSD-current before 1998/05/26 suffer from this problem. Corrected: FreeBSD-current as of 1998/05/26 FreeBSD-stable as of 1998/05/26 FreeBSD only: yes Patches: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-98:06/ ============================================================================= IMPORTANT MESSAGE: The FreeBSD security officer now uses the policy ftp://ftp.freebsd.org/pub/FreeBSD/POLICY.asc for sending out advisories. ============================================================================= I. Background As can be read in CERT advisory CA-98.01.smurf, there exists a denial of service attack called "smurfing". This attack sends ICMP echo requests to the broadcast address of a network. This results in the source address of the ICMP packets being flooded with ICMP echo replies. Of course, the source address is spoofed. II. Problem Description A solution at the intermediate network being abused to generate the ICMP echo replies is to either block ICMP echo requests directed to a broadcast address or to configure the hosts on that network not to respond to such an ICMP request. In the CERT advisory, the following was reported: In FreeBSD 2.2.5 and up, the tcp/ip stack does not respond to ICMP echo requests destined for broadcast and multicast addresses by default. This behavior can be changed via the sysctl command via mib net.inet.icmp.bmcastecho. Unfortunately, an error was made with the implementation of this functionality and, despite the text in the CERT advisory, the net.inet.icmp.bmcastecho sysctl variable default is to respond to ICMP packets sent to the networks broadcast address. You should explicitly run the command sysctl -w net.inet.icmp.bmcastecho=0 to disable this. III. Impact Your network can suffer performance degradation when a large amount of spoofed ICMP is sent to your broadcast address. IV. Workaround Block ICMP echo requests to broadcast addresses in your kernel using ipfw(8). See CERT advisory CA-98.01.smurf for more workarounds. V. Solution Apply the following patch: Patch for 3.0-current, 2.2-stable, 2.2.5 and 2.2.6 systems: Index: ip_icmp.c =================================================================== RCS file: /home/cvsup/freebsd/CVS/src/sys/netinet/ip_icmp.c,v retrieving revision 1.29 retrieving revision 1.30 diff -u -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,8 +375,7 @@ case ICMP_ECHO: if (!icmpbmcastecho - && (m->m_flags & (M_MCAST | M_BCAST)) != 0 - && IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) { + && (m->m_flags & (M_MCAST | M_BCAST)) != 0) { icmpstat.icps_bmcastecho++; break; } @@ -385,8 +384,7 @@ case ICMP_TSTAMP: if (!icmpbmcastecho - && (m->m_flags & (M_MCAST | M_BCAST)) != 0 - && IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) { + && (m->m_flags & (M_MCAST | M_BCAST)) != 0) { icmpstat.icps_bmcasttstamp++; break; } ============================================================================== CERT-NL is the Computer Emergency Response Team for SURFnet customers. SURFnet is the Dutch network for educational, research and related institutes. CERT-NL is a member of the Forum of Incident Response and Security Teams (FIRST). All CERT-NL material is available under: http://www.surfnet.nl/surfnet/security/cert-nl.html ftp://ftp.surfnet.nl/surfnet/net-security In case of computer or network security problems please contact your local CERT/security-team or CERT-NL (if your institute is NOT a SURFnet customer please address the appropriate (local) CERT/security-team). CERT-NL is one/two hour(s) ahead of UTC (GMT) in winter/summer, i.e. UTC+0100 in winter and UTC+0200 in summer (DST). Email: cert-nl@surfnet.nl ATTENDED REGULARLY ALL DAYS Phone: +31 302 305 305 BUSINESS HOURS ONLY Fax: +31 302 305 329 BUSINESS HOURS ONLY Snailmail: SURFnet bv Attn. CERT-NL P.O. Box 19035 NL - 3501 DA UTRECHT The Netherlands NOODGEVALLEN: 06 52 87 92 82 ALTIJD BEREIKBAAR EMERGENCIES : +31 6 52 87 92 82 ATTENDED AT ALL TIMES CERT-NL'S EMERGENCY PHONENUMBER IS ONLY TO BE USED IN CASE OF EMERGENCIES: THE SURFNET HELPDESK OPERATING THE EMERGENCY NUMBER HAS A *FIXED* PROCEDURE FOR DEALING WITH YOUR ALERT AND WILL IN REGULAR CASES RELAY IT TO CERT-NL IN AN APPROPRIATE MANNER. CERT-NL WILL THEN CONTACT YOU. ============================================================================== -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.5.3i for non-commercial use iQCVAwUBNX7l0lpSTqmIRWKVAQH8vQP/bTm34W+LfXjUtmDpefXQESxsAooPUmxb qpGrmvPJAb49ulEqrT+RqlGZew4nB4J7/5+ePTN/PTDFsLg3zNxTjD/dhSk5trGS LMWUsvcT65WfBHsqvz7HXrz4zfKZU8YN71pK2pjCvqvmnLVJGqKcHos9Q5bXP0AX qDSMLxJsx9c= =P2Gh -----END PGP SIGNATURE-----