******************************************************************************
             ------               -----   -----  ---     -----
             |      ----- ----   |          |    |  |   |
             |---   |     |   |  |          |    |  |   |
             |      |--   |   |  |          |    |--    |
             |      |     |   |  |          |    | \    |
             |      ----- ----    -----   -----  |  \    -----

                               A D V I S O R Y

           FA-98.23
******************************************************************************
Topic: LAND attack can cause harm to running FreeBSD systems
Source: CIAC

Creation Date: March 16,1998
Last Updated:

To aid in the wide distribution of essential security information, FedCIRC 
is forwarding the following information from CIAC bulletin I-036. 
FedCIRC urges you to act on this information as soon as possible.

If you have any questions, please contact FedCIRC:

        Telephone:      +1 888 282 0870
        Email:          fedcirc@fedcirc.gov



=======================FORWARDED TEXT STARTS HERE============================

-----BEGIN PGP SIGNED MESSAGE-----

             __________________________________________________________

                       The U.S. Department of Energy
                    Computer Incident Advisory Capability
                           ___  __ __    _     ___
                          /       |     /_\   /
                          \___  __|__  /   \  \___
             __________________________________________________________

                             INFORMATION BULLETIN

                     FreeBSD Denial-of-Service LAND Attacks

March 16, 1998 23:00 GMT                                          Number I-036
______________________________________________________________________________
PROBLEM:       A vulnerability exists in most FreeBSD derived stacks.
PLATFORM:      FreeBSD 2.1.*, FreeBSD 2.2.0R, 2.2.1R, 2.2.5R FreeBSD-stable
               and FreeBSD current
DAMAGE:        If exploited, this vulnerability may allow a malicious user
               to send a packet that can cause the system to lock up, thus
               producing a denial of service attack.
SOLUTION:      Apply patches or workaround listed below.
______________________________________________________________________________
VULNERABILITY  This vulernability is being widely exploited.  Unprotected
ASSESSMENT:    systems crash and lose any unsaved data when this attack
               occurs.
______________________________________________________________________________

[ Start FreeBSD Advisory ]

=============================================================================
FreeBSD-SA-98:01                                            Security Advisory
                                                                FreeBSD, Inc.

Topic:          LAND attack can cause harm to running FreeBSD systems

Category:       core
Module:         kern
Announced:      1997-12-01
Affects:        FreeBSD 2.1.*, FreeBSD 2.2.0R, 2.2.1R, 2.2.5R
                FreeBSD-stable and FreeBSD-current
Doesn't Affect: FreeBSD 2.2.2R
Corrected:      FreeBSD 2.2.6R, FreeBSD-current as of Jan 21, 1998
                FreeBSD-stable as of Jan 30, 1998
FreeBSD only:   no

Patches:        ftp://ftp.freebsd.org/pub/CERT/patches/SA-98:01/

=============================================================================
IMPORTANT MESSAGE: The FreeBSD advisory archive has moved from
ftp://freebsd.org/pub/CERT to ftp://ftp.freebsd.org/pub/CERT
=============================================================================

I.   Background

     In most TCP stacks state is kept based on the source and
     destination address of a packet received.

II.  Problem Description

     A problem exists in most FreeBSD derived stacks that allows a
     malicious user to send a packet that causes the sytsem to lock
     up, thus producing a denial of service attack.

III. Impact

     Any person on the Internet who can send a FreeBSD machine a
     packet can cause it to lock up and be taken out of service.
    
IV.  Workaround

     A firewall can be used to filter packets from the Internet that
     appear to be from your local network.  This will not eliminate
     the threat, but will eliminate external attacks.

V.   Solution

     Apply the enclosed patch.  There are two patches, one for FreeBSD
     -current, and another for FreeBSD 2.2-stable.

    patch for -current prior to Jan 21, 1998.  Found in land-current.

    Index: tcp_input.c
    ===================================================================
    RCS file: /home/imp/FreeBSD/CVS/src/sys/netinet/tcp_input.c,v
    retrieving revision 1.67
    retrieving revision 1.68
    diff -u -r1.67 -r1.68
    --- tcp_input.c     1997/12/19 23:46:15     1.67
    +++ tcp_input.c     1998/01/21 02:05:59     1.68
    @@ -626,6 +613,7 @@
         * If the state is LISTEN then ignore segment if it contains an RST.
         * If the segment contains an ACK then it is bad and send a RST.
         * If it does not contain a SYN then it is not interesting; drop it.
    +    * If it is from this socket, drop it, it must be forged.
         * Don't bother responding if the destination was a broadcast.
         * Otherwise initialize tp->rcv_nxt, and tp->irs, select an initial
         * tp->iss, and send a segment:
    @@ -644,6 +632,9 @@
                        goto dropwithreset;
                if ((tiflags & TH_SYN) == 0)
                        goto drop;
    +           if ((ti->ti_dport == ti->ti_sport) &&
    +               (ti->ti_dst.s_addr == ti->ti_src.s_addr))
    +                   goto drop;
                /*
                 * RFC1122 4.2.3.10, p. 104: discard bcast/mcast SYN
                 * in_broadcast() should never return true on a received
    @@ -762,6 +753,23 @@
                }
    
        /*
    +    * If the state is SYN_RECEIVED:
    +    *      if seg contains SYN/ACK, send a RST.
    +    *      if seg contains an ACK, but not for our SYN/ACK, send a RST.
    +    */
    +   case TCPS_SYN_RECEIVED:
    +           if (tiflags & TH_ACK) {
    +                   if (tiflags & TH_SYN) {
    +                           tcpstat.tcps_badsyn++;
    +                           goto dropwithreset;
    +                   }
    +                   if (SEQ_LEQ(ti->ti_ack, tp->snd_una) ||
    +                       SEQ_GT(ti->ti_ack, tp->snd_max))
    +                           goto dropwithreset;
    +           }
    +           break;
    +
    +   /*
         * If the state is SYN_SENT:
         *      if seg contains an ACK, but not for our SYN, drop the input.
         *      if seg contains a RST, then drop the connection.
    @@ -1176,14 +1184,11 @@
        switch (tp->t_state) {
    
        /*
    -    * In SYN_RECEIVED state if the ack ACKs our SYN then enter
    -    * ESTABLISHED state and continue processing, otherwise
    -    * send an RST.
    +    * In SYN_RECEIVED state, the ack ACKs our SYN, so enter
    +    * ESTABLISHED state and continue processing.
    +    * The ACK was checked above.
         */
        case TCPS_SYN_RECEIVED:
    -           if (SEQ_GT(tp->snd_una, ti->ti_ack) ||
    -               SEQ_GT(ti->ti_ack, tp->snd_max))
    -                   goto dropwithreset;
    
                tcpstat.tcps_connects++;
                soisconnected(so);

    patch for 2.2.5 and 2.2.5-stable before Jan 30, 1998 found in land-22

    Index: tcp_input.c
    ===================================================================
    RCS file: /home/imp/FreeBSD/CVS/src/sys/netinet/tcp_input.c,v
    retrieving revision 1.54.2.6
    retrieving revision 1.54.2.7
    diff -u -r1.54.2.6 -r1.54.2.7
    --- tcp_input.c     1997/11/20 21:45:34     1.54.2.6
    +++ tcp_input.c     1998/01/30 19:13:55     1.54.2.7
    @@ -627,6 +614,7 @@
         * If the state is LISTEN then ignore segment if it contains an RST.
         * If the segment contains an ACK then it is bad and send a RST.
         * If it does not contain a SYN then it is not interesting; drop it.
    +    * If it is from this socket, drop it, it must be forged.
         * Don't bother responding if the destination was a broadcast.
         * Otherwise initialize tp->rcv_nxt, and tp->irs, select an initial
         * tp->iss, and send a segment:
    @@ -646,6 +634,9 @@
                        goto dropwithreset;
                if ((tiflags & TH_SYN) == 0)
                        goto drop;
    +           if ((ti->ti_dport == ti->ti_sport) &&
    +               (ti->ti_dst.s_addr == ti->ti_src.s_addr))
    +                   goto drop;
                /*
                 * RFC1122 4.2.3.10, p. 104: discard bcast/mcast SYN
                 * in_broadcast() should never return true on a received
    @@ -765,6 +756,23 @@
                }
    
        /*
    +    * If the state is SYN_RECEIVED:
    +    *      if seg contains SYN/ACK, send a RST.
    +    *      if seg contains an ACK, but not for our SYN/ACK, send a RST.
    +    */
    +   case TCPS_SYN_RECEIVED:
    +           if (tiflags & TH_ACK) {
    +                   if (tiflags & TH_SYN) {
    +                           tcpstat.tcps_badsyn++;
    +                           goto dropwithreset;
    +                   }
    +                   if (SEQ_LEQ(ti->ti_ack, tp->snd_una) ||
    +                       SEQ_GT(ti->ti_ack, tp->snd_max))
    +                           goto dropwithreset;
    +           }
    +           break;
    +
    +   /*
         * If the state is SYN_SENT:
         *      if seg contains an ACK, but not for our SYN, drop the input.
         *      if seg contains a RST, then drop the connection.
    @@ -1179,14 +1187,11 @@
        switch (tp->t_state) {
    
        /*
    -    * In SYN_RECEIVED state if the ack ACKs our SYN then enter
    -    * ESTABLISHED state and continue processing, otherwise
    -    * send an RST.
    +    * In SYN_RECEIVED state, the ack ACKs our SYN, so enter
    +    * ESTABLISHED state and continue processing.
    +    * The ACK was checked above.
         */
        case TCPS_SYN_RECEIVED:
    -           if (SEQ_GT(tp->snd_una, ti->ti_ack) ||
    -               SEQ_GT(ti->ti_ack, tp->snd_max))
    -                   goto dropwithreset;
    
                tcpstat.tcps_connects++;
                soisconnected(so);
   

=============================================================================
FreeBSD, Inc.

Web Site:                       http://www.freebsd.org/
Confidential contacts:          security-officer@freebsd.org
PGP Key:                        ftp://ftp.freebsd.org/pub/CERT/public_key.asc
Security notifications:         security-notifications@freebsd.org
Security public discussion:     security@freebsd.org

Notice: Any patches in this document may not apply cleanly due to
        modifications caused by digital signature or mailer software.
        Please reference the URL listed at the top of this document
        for original copies of all patches if necessary.
=============================================================================

[ End FreeBSD Advisory ]

______________________________________________________________________________

CIAC wishes to acknowledge the contributions of FreeBSD, Inc. for the
information contained in this bulletin.
______________________________________________________________________________


CIAC, the Computer Incident Advisory Capability, is the computer
security incident response team for the U.S. Department of Energy
(DOE) and the emergency backup response team for the National
Institutes of Health (NIH). CIAC is located at the Lawrence Livermore
National Laboratory in Livermore, California. CIAC is also a founding
member of FIRST, the Forum of Incident Response and Security Teams, a
global organization established to foster cooperation and coordination
among computer security teams worldwide.

CIAC services are available to DOE, DOE contractors, and the NIH. CIAC
can be contacted at:
    Voice:    +1 925-422-8193
    FAX:      +1 925-423-8002
    STU-III:  +1 925-423-2604
    E-mail:   ciac@llnl.gov

For emergencies and off-hour assistance, DOE, DOE contractor sites,
and the NIH may contact CIAC 24-hours a day. During off hours (5PM -
8AM PST), call the CIAC voice number 925-422-8193 and leave a message,
or call 800-759-7243 (800-SKY-PAGE) to send a Sky Page. CIAC has two
Sky Page PIN numbers, the primary PIN number, 8550070, is for the CIAC
duty person, and the secondary PIN number, 8550074 is for the CIAC
Project Leader.

Previous CIAC notices, anti-virus software, and other information are
available from the CIAC Computer Security Archive.

   World Wide Web:      http://www.ciac.org/
                        (or http://ciac.llnl.gov -- they're the same machine)
   Anonymous FTP:       ftp.ciac.org
                        (or ciac.llnl.gov -- they're the same machine)
   Modem access:        +1 (925) 423-4753 (28.8K baud)
                        +1 (925) 423-3331 (28.8K baud)

CIAC has several self-subscribing mailing lists for electronic
publications:
1. CIAC-BULLETIN for Advisories, highest priority - time critical
   information and Bulletins, important computer security information;
2. SPI-ANNOUNCE for official news about Security Profile Inspector
   (SPI) software updates, new features, distribution and
   availability;
3. SPI-NOTES, for discussion of problems and solutions regarding the
   use of SPI products.

Our mailing lists are managed by a public domain software package
called Majordomo, which ignores E-mail header subject lines. To
subscribe (add yourself) to one of our mailing lists, send the
following request as the E-mail message body, substituting
ciac-bulletin, spi-announce OR spi-notes for list-name:

E-mail to       ciac-listproc@llnl.gov or majordomo@tholia.llnl.gov:
        subscribe list-name
  e.g., subscribe ciac-bulletin

You will receive an acknowledgment email immediately with a confirmation
that you will need to mail back to the addresses above, as per the
instructions in the email.  This is a partial protection to make sure
you are really the one who asked to be signed up for the list in question.

If you include the word 'help' in the body of an email to the above address,
it will also send back an information file on how to subscribe/unsubscribe,
get past issues of CIAC bulletins via email, etc.

PLEASE NOTE: Many users outside of the DOE, ESnet, and NIH computing
communities receive CIAC bulletins.  If you are not part of these
communities, please contact your agency's response team to report
incidents. Your agency's team will coordinate with CIAC. The Forum of
Incident Response and Security Teams (FIRST) is a world-wide
organization. A list of FIRST member organizations and their
constituencies can be obtained via WWW at http://www.first.org/.

This document was prepared as an account of work sponsored by an
agency of the United States Government. Neither the United States
Government nor the University of California nor any of their
employees, makes any warranty, express or implied, or assumes any
legal liability or responsibility for the accuracy, completeness, or
usefulness of any information, apparatus, product, or process
disclosed, or represents that its use would not infringe privately
owned rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark, manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation or favoring by the United States Government or the
University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government or the University of California, and shall not be used for
advertising or product endorsement purposes.

LAST 10 CIAC BULLETINS ISSUED (Previous bulletins available from CIAC)

I-026: Vulnerability in ssh-agent
I-027B: HP-UX Vulnerabilities (CUE, CDE, land)
I-028: Vulnerabilities in CDE
I-029: IBM AIX Telnet Denial-of-Service Vulnerability
I-030: SunOS volrmmount (1) Vulnerability
I-031A: WindowsNT-95 Attacks on DOE Sites
I-032: Sun Solaris Vulnerabilities (vacation, dtaction)
I-033: Sun Solaris Vulnerabilities (ndd, rpc.cmsd)
I-034: Internet Cookies
I-035: SGI Vulnerabilities (startmidi/stopmidi, datman/cdman, cdplayer)




-----BEGIN PGP SIGNATURE-----
Version: 4.0 Business Edition

iQCVAwUBNRA85bnzJzdsy3QZAQEmXAQA1gxJnAR2ZV3xZOVqsx/sNN/0mauo5ZQU
1059eeBffiZe/DPTeEt+Di1bn9sdUgAVZIunLny0D8NxtzE/j//esEtwexbGTC6i
8PI8diWCuiqwwCHAChQAJmLcpAVDiIOF7P+pBTT18qvDrxdA0GP1En9B88pAc/88
PKqra8E0Vn4=
=rFoZ
-----END PGP SIGNATURE-----


========================FORWARDED TEXT ENDS HERE=============================

The National Institute of Standards and Technology (NIST) has
established a Federal Computer Incident response Capability (FedCIRC)
to assist federal civilians agencies in their incident handling
efforts by providing proactive and reactive computer security related
services.  FedCIRC is a partnership among NIST, the Computer Incident
Advisory Capability (CIAC), and the CERT* Coordination Center
(CERT/CC). 

If you believe that your system has been compromised, please contact
FedCIRC: 

        Telephone:      +1 888 282 0870
        Email:          fedcirc@fedcirc.gov
        Web Server:     http://www.fedcirc.gov/

* Registered in U.S. Patent and Trademark Office
 
The CERT Coordination Center is part of the Software Engineering
Institute.  The Software Engineering Institute is sponsored by the
U.S. Department of Defense.

CIAC, the Computer Incident Advisory Capability, is the computer
security incident response team for the U.S. Department of Energy
(DOE) and the emergency backup response team for the National
Institutes of Health (NIH). CIAC is located at the Lawrence Livermore
National Laboratory in Livermore, California. CIAC is also a founding
member of FIRST, the Forum of Incident Response and Security Teams, a
global organization established to foster cooperation and coordination
among computer security teams worldwide.
 
This document was prepared as an account of work sponsored by an
agency of the United States Government. Neither the United States
Government nor the University of California nor any of their
employees, makes any warranty, express or implied, or assumes any
legal liability or responsibility for the accuracy, completeness, or
usefulness of any information, apparatus, product, or process
disclosed, or represents that its use would not infringe privately
owned rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark, manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation or favoring by the United States Government or the
University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government or the University of California, and shall not be used for
advertising or product endorsement purposes.