From mark.graff@ENG.SUN.COM Thu Oct 10 14:45:45 1996
Date: Thu, 10 Oct 1996 11:22:16 -0500
From: Mark Graff <mark.graff@ENG.SUN.COM>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@netspace.org>
Subject: Sun Security Bulletin #136

=============================================================================
         SUN MICROSYSTEMS SECURITY BULLETIN: #00136, 9 Oct 1996
=============================================================================

BULLETIN TOPICS

In this bulletin Sun discusses the TCP-based "SYN flood" denial-
of-service attack. We suggest ways to tune most Solaris/SunOS systems
to make them more resistant, and explain which releases and
configurations stand up best. We also discuss which customers are most
likely to be affected, and the degree to which firewalls and similar
insulating arrangements can protect an enterprise from this attack.

This Bulletin also describes the patches and other changes Sun commits
to making in the future in response to the emergence of such attacks.

This denial-of-service attack, which affects all operating systems
which implement the TCP protocol, has previously been discussed in
CERT(sm) Advisory CA-96.21, issued on 19 September 96. Attacks against
several prominent service providers have been well documented in the
last several weeks in Time magazine, the Wall Street Journal, and many
other national and international periodicals.

I.   What has Happened, Who is Affected, What to Do

II.  Understanding the Vulnerability

III. Technical Recommendations

IV.  Plans and Schedules



APPENDICES

A.   Queuing Capacity Vs. Attack Rates

B.   How to obtain Sun security patches

C.   How to report or inquire about Sun security problems

D.   How to obtain Sun security bulletins or short status updates


         Send Replies or Inquiries To:

         Mark Graff
         Sun Security Coordinator
         MS MPK17-103
         2550 Garcia Avenue
         Mountain View, CA 94043-1100

         Phone: 415-786-5274
         Fax:   415-786-7994
         E-mail: security-alert@Sun.COM


Keywords:       TCP, SYN, denial-of-service
Patchlist:
Cross-Ref:      CERT CA-96.21

                                -----------

Permission is granted for the redistribution of this Bulletin, so long
as the Bulletin is not edited and is attributed to Sun Microsystems.
Portions may also be excerpted for re-use in other security advisories
so long as proper attribution is included.

Any other use of this information without the express written consent
of Sun Microsystems is prohibited. Sun Microsystems expressly disclaims
all liability for any misuse of this information by any third party.

=============================================================================
         SUN MICROSYSTEMS SECURITY BULLETIN: #00136, 9 Oct 1996
=============================================================================


I.   What has Happened, Who is Affected, What to Do

    A. What has Happened

    Late this summer, an electronic "hacker journal" published complete
    source code for a program to mount a so-called "TCP SYN flood"
    attack, in which a targeted system is bombarded with requests for a
    certain kind of network connection. Such an attack cannot
    compromise the security of a targeted system--no one can "break in"
    using it--but it can tie up the system, making it unavailable to
    respond to legitimate users. Some systems may even crash, if key
    system resources are exhausted.

    Within a few weeks after the release of the source code, several
    Internet service providers had been victimized by this "denial-of-
    service" attack. To date, published reports indicate that several
    dozen such attacks have been carried out, not only against
    commercial service providers but also popular non-profit sites,
    such as the Internet Chess Club.

    Because the complete source to the program, with instructions for
    use, was published, it takes little technical knowledge to mount
    the attack.  Further, because the program takes steps to conceal
    which system is sending the packets, it's proved difficult (though
    not impossible) to trace an attack to its source. For these
    reasons--and although relatively few sites out of the Internet's
    tens of millions have been affected--Sun, along with many other
    software makers and computer security experts around the world, has
    worked hard since the day the attacks were announced to evaluate
    both the attack and the many countermeasures which have been
    proposed.

    This bulletin summarizes what we have learned, and gives the best
    advice we have today about which Sun customers may be vulnerable
    --and what those sites can do to protect themselves.

    B. Who is Affected

    The only systems which are vulnerable to this attack are those
    (such as Web servers, FTP servers, or mail servers) which directly
    accept TCP connection requests from other systems on the Internet.

    Most systems behind firewalls are safe. However, some firewalls are
    configured to pass through connection requests on particular ports
    to server systems behind the firewall. In such cases the server
    could well be vulnerable to a SYN flood attack.

    If you are not sure whether your systems accept TCP conection
    requests directly from systems on the Internet, check with your
    Network Administrator.

    C. What to Do

    If your Solaris/SunOS systems are vulnerable to the TCP SYN flood
    attack, there are several immediate steps you may be able to take
    to protect them.

    1. Apply the parametric adjustments and other changes described in
       our "Technical Recommendations" section as soon as possible.
       (Note that some of the changes require access to source code.)
       When patches become available, as described under "Plans and
       Schedules", obtain and install them.

    2. Consider adding additional physical memory to any systems which,
       as described in section II.D.3, would benefit from it.

    3. If your system is running one of the older versions of the SunOS
       operating system, such as SunOS 4.1.3, 4.1.3_U1, or 4.1.4, or
       5.3 (Solaris 2.3), consider upgrading to a later release.

       Solaris 2.4, 2.5, and 2.5.1 systems stand up to this attack much
       better than earlier releases, especially after tuning, because
       of the cumulative effect of several TCP-related improvements.
       The earlier releases can withstand only very light attacks, if
       any. Some details are provided under "Understanding the
       Vulnerability".

    4. Review which incoming ports your system services. Pare that
       list down to essentials. One way to determine which ports your
       system is currently listening to by executing a command such
       as:

          netstat -a -f inet | grep LISTEN

       On Solaris 2.4 and later systems, you can obtain much the same
       information with the simpler command:

          ndd /dev/tcp tcp_listen_hash

       To reduce the number of ports listened to by inetd, edit the
       file /etc/inetd.conf and comment out any unneeded entries.

    5. Consider installing--especially if you are a 4.1.x customer--a
       firewall, or a hardware filter, or one of the new third-party
       software packages. (Sun has not tested and does not currently
       endorse any of the new products, such as Checkpoint's
       "SYNDefender", now being marketed to defend against this
       attack.)


II.  Understanding the Vulnerability

    A. How the SYN Flood Attack Works

       The attack exploits a basic design element of the "TCP
       protocol", a set of rules developed many years ago to govern a
       certain class of conversations between computers. Here is a
       description, extracted from the recent CERT advisory CA-96.21.

          When a system (called the client) attempts to establish a TCP
          connection to a system providing a service (the server), the
          client and server exchange a set sequence of messages. This
          connection technique applies to all TCP connections--telnet,
          Web, email, etc.

          The client system begins by sending a SYN message to the
          server. The server then acknowledges the SYN message by
          sending SYN-ACK message to the client. The client then
          finishes establishing the connection by responding with an
          ACK message. The connection between the client and the server
          is then open, and the service-specific data can be exchanged
          between the client and the server. Here is a view of this
          message flow:


                Client                  Server
                ------                  ------
                SYN-------------------->

                   <--------------------SYN-ACK

                ACK-------------------->

                     Client and server can now
                     send service-specific data


         The potential for abuse arises at the point where the server
         system has sent an acknowledgment (SYN-ACK) back to the client
         but has not yet received the ACK message....

         The attacking system sends [a flood of] SYN messages to the
         victim server system; these appear to be legitimate but in
         fact reference a client system that is unable to respond to
         the SYN-ACK messages.

       Bombarding a system with, say, dozens of falsified connection
       requests a minute can seriously degrade its ability to give
       service to legitimate connection requests. This is why the
       attack is said to "deny service" to the system's users.

    B. How To Tell If Your System Is Under Attack

       1. Checking for Connections in the "SYN_RCVD" State

       A system under attack may appear to be running normally in most
       respects. Outgoing connections, for example, and logged-in users
       may be serviced normally. The symptoms of the attack will most
       likely be noticed when someone attempts an incoming connection
       --for example, by trying to reach a Web site on the target
       system.  Depending on the rate of attack (and how resistant it
       is), the system will react sluggishly, or not at all, to such
       incoming connection requests.

       One way a system administrator can check to see whether an
       attack is in progress is to monitor the number of TCP
       connections in the "SYN_RCVD" state, via a command such as the
       following.

          netstat -an -f inet | grep SYN_RCVD | wc -l

       Comparing the value returned by this command to a known-normal
       value will give a good indication of whether the system is under
       attack.

       2. Using TCP Transaction Statistics

       The above check for the "SYN_RCVD" state will work for all
       Solaris/SunOS systems. More refined tools are available under
       Solaris 2.x systems, which maintain TCP transaction statistics.

       Display the TCP transaction statistics with a command such as:

          netstat -s -P tcp

       The "tcpTimRetransDrop" parameter shows the number of aborts
       since boot time due to abort timer expirations. This count
       includes both SYN requests and established TCP connections.

       The "tcpListenDrop" parameter, introduced in Solaris 2.5.1,
       shows the number of SYN requests that have been refused since
       boot time due to "backlog full" conditions.

       You may see occasional "tcpListenDrop" incidents on a normal,
       busy 2.5.1 system. (This can happen, for example, when the
       loaded system is not able to schedule the server daemon soon
       enough to service incoming SYN requests, so that they fill up
       the daemon's backlog queue.) But if you see the "tcpListenDrop"
       count going up very quickly, with "tcpTimRetransDrop" events
       following that rise, your system may well be under a SYN
       attack.

    C. Our Testing

       The first incidents were announced a few weeks ago. Since then
       Sun has obtained several versions of SYN flood attack software,
       and tested the most effective of them against every supported
       SunOS version.  A complex mix of hardware configurations were
       included in the testing, being combined with the different
       operating system releases to produce a test matrix with dozens
       of combinations.

       Basing our trials on publicly and privately obtained information
       about the rates and durations of the attacks, we reproduced in
       our testing two common modes. The "light" attack consisted of a
       few falsified SYN requests a second. The "heavy" attack
       consisted of hundreds (even thousands) such packets per second.

    D. How Sun Systems Stand Up

       Our testing indicates that even a light SYN flood attack will
       often succeed against Solaris/SunOS systems which have not been
       either shielded from it or hardened against it. After such steps
       have been taken, newer and larger systems can generally
       withstand even a heavy attack; systems running older releases of
       SunOS--especially those with relatively small amounts of memory,
       say 64 MB--still succumb.

       We have seen the following regularities apply.

       1. Faster hardware does better than slower hardware. The CPU
          time required to handle the flood of connection requests
          represents less of a resource drain.

       2. Newer versions of SunOS react much better than older
          versions.  Specifically, we have found that Solaris 2.5.1,
          2.5, and 2.4 (SunOS 5.5.1, 5.5, and 5.4) perform better under
          attack than SunOS 5.3, 4.1.4, 4.1.3_U1, and 4.1.3.

       3. Systems with plenty of physical memory react better than
          systems with less memory, so long as the operating system is
          able to make use of the extra memory to create and manage a
          sizable queue. Systems with only 64 MB of memory may well
          benefit from an increase. Systems already at 128 MB or above
          might not. See appendix A for a formula you can use to help
          make this determination.

          SunOS 4.1.x systems cannot effectively make use of more than
          2 MB of memory for queue entries, because of a systemic
          limitation in the management of "mbufs". For this reason
          adding extra memory will not help harden a 4.1.x system to
          this attack.

          SunOS 5.3 (Solaris 2.3) also fares little better under this
          attack with "extra" memory, though for different reasons.
          The capacity to cope with memory demands dynamically was one
          of the features improved in Solaris 2.4. It shows.

       4. Systems which do not need to service legitimate connection
          requests over slow asynchronous lines fare much better than
          those which do. This is because setting a very low timeout
          value for connection requests helps the system clean up fake
          requests quickly, but may cause an unacceptably high timeout
          rate for legitimate connections over slow links.

       Our conclusion after testing: without adjustment, no version of
       Solaris/SunOS can be relied upon to withstand a heavy (hundreds
       of packets a second) SYN flood attack. After parametric tuning,
       Solaris 2.4 and later releases stand up very well. Earlier
       versions, including Solaris 2.3, may withstand a very light
       attack but remain susceptible to moderate and heavy ones.


III. Technical Recommendations

The two most effective adjustments which you can make quickly to
protect your Solaris/SunOS systems against the SYN flood attack are to
(1) shorten the value of the abort timer, and (2) lengthen the backlog
queue for those TCP ports which might be bombarded. On Solaris 2.x
systems, these changes can be made using the ndd program. Rebuilding
the kernel is required to adjust the behavior of 4.1.x systems.

The two changes each increase the capacity of the system to queue and
process all TCP connection requests, whether valid or invalid.

Increasing the length of the backlog queue will have no effect unless
you also make an adjustment involving the listen() call on the affected
port(s). You will need to either rebuild from source the listener
applications your systems use, or patch the binaries.  See paragraph C
below for some more information.

Lowering the abort timeout is a very effective measure to take against
SYN attacks.  Changing this parameter, however, will have a side effect
that some sites may find unacceptable: outgoing connection requests,
initiated by users already on the adjusted system, will time out in
less time than before. This side effect occurs because the system uses
the same abort timer for both incoming and outgoing connections.

Will adding physical memory improve your system's ability to withstand
the attack? It's possible; the answer depends on how much memory your
system has now, how many ports service incoming connections, how low
you can set the abort timer value, and which version of the operating
system (see section II.D.3) your system is running.

See Appendix A for a more detailed discussion of the relationship between
the effects of queue length, abort timeout, and available memory.

For information about more sophisticated, design-level approaches we
are working on (which all involve source code changes), see section
IV.

    A. Decreasing the Abort Timeout Value

       Solaris/SunOS systems are distributed with timeout values set
       either to four minutes (SunOS 5.3 and earlier 5.x) or three
       minutes (SunOS 5.4 and later). For 4.1.x the timeout is 75
       seconds. These values were selected to ensure reasonable
       performance over slow asynchronous lines, which can incur very
       long delays.

       Lower values allow the system to purge falsified connection
       requests faster. In our testing, values in the range of ten
       seconds gave the best results in configurations which did not
       include asynchronous lines. However, setting the abort timer to
       such a low value may very likely cause unsatisfactory results if
       connections involving asynchronous lines must be serviced. In
       those cases, a value in the range of one minute may give more
       satisfactory results.

       1. Instructions for Solaris 2.x systems.

          On Solaris 2.x systems, you can set the abort timer value with a
          command similar to:

          ndd -set /dev/tcp tcp_ip_abort_cinterval 10000

          The timeout value, here ten seconds, is given in milliseconds.
          To make the change permanent, add the command to the file
          /etc/init.d/inetinit.

          Note that, as described above, this new value will also affect
          outgoing connections.

       2. Instructions for SunOS 4.1.x systems.

          We list here two possible approaches. Each involves rebuilding
          the kernel.

          Note that because the value is interpreted here as being in
          half-second units, you must change the parametric value to
          20 to reduce the timeout to, for example, 10 seconds.

          a. Place the value of the abort timer in a variable, so that
          it can be changed with adb. This approach is the one we
          expect to take in an upcoming 4.1.x kernel patch.

          Here are diff files (the example is taken from our 4.1.4
          source) showing one way to effect that change.

             tcp_input..c:
             > /* adjustable variable to replace TCPTV_KEEP_INIT */
             > int tcptv_keep_init = TCPTV_KEEP_INIT;
             444c446
             <               tp->t_timer[TCPT_KEEP] = TCPTV_KEEP_INIT;
             ---
             >               tp->t_timer[TCPT_KEEP] = tcptv_keep_init;

          After editing the file, you would need to put the modified
          tcp_input.c file in /sys/netinet and rebuild a kernel.

          b. Change the abort timer value parameter, TCPTV_KEEP_INIT,
          and rebuild the kernel. The parameter is defined in the
          header file /sys/netinet/tcp_timer.h.

          This approach is slightly simpler but has the side effect
          on outgoing connections discussed earlier.

          After editing the header file, you would need to rebuild
          a kernel, ensuring that the tcp_input.c was re-compiled.

    B. Lengthening the Per-Port Backlog Queue

       Solaris 2.4 and 2.3 systems, and 4.1.x systems, are distributed
       with a maximum backlog queue length of 5. For Solaris 2.5 and
       2.5.1, the value was increased to 32. To harden your system
       against SYN flood attacks, you probably need a value in the
       thousands.

       In the examples below we show how to set the actual per-port max
       value to 8,192. During our testing the number of queue entries
       never exceeded this number, no matter how fast we bombarded the
       system with SYN requests.

       1. Instructions for Solaris 2.x systems.

          Lengthening the backlog queue is a two-step process. Before
          increasing the value of the parameter which controls how many
          connections may be queued per port, it is necessary to change
          the maximum value the system will range-check the new setting
          against.

          a. First, change the upper limit the system will enforce. This
          can be done with adb. One approach is to effect the change in
          a startup file, then reboot the system. To change the upper
          limit to a value of 10,240, append the following line to the
          file /etc/init.d/inetinit:

          echo "tcp_param_arr+14/W 0t10240" | adb -kw /dev/ksyms /dev/mem

          b. Next, change the system parameter specifying the per-port
          backlog queue length. This can be done with the ndd program.

          ndd -set /dev/tcp tcp_conn_req_max 8192

          The parametric value you specify must be less than or equal to
          the upper limit set in the previous step (as in this case the
          value of 8,192 is less than the upper limit of 10,240).

          After executing the ndd command, you will need to restart the
          listener daemons for the change to tcp_conn_req_max to have
          any effect. The queue data structures are created at the time
          the listen() call is handled.

          To make the change permanent, add the command to the file
          /etc/init.d/inetinit.

       2. Instructions for SunOS 4.1.x systems.

          We list here three possible approaches. The first two are
          equivalent. All involve rebuilding the kernel.

          What is the best value for SOMAXCONN, the maximum per-port
          backlog queue value parameter? The answer will vary,
          depending on how your system is used. Values between 100-500
          are good places to start. Just how high a value can safely be
          used depends primarily on how many ports are likely to be
          attacked.

          In SunOS 4.1.x systems only 2MB of memory can be allocated
          for mbufs. A heavy attack into a long queue can exhaust the
          system's supply of mbufs quickly.

          Since SOMAXCONN is used to limit the queue length for each
          port, a value of 1,000 may be safe if connections to only one
          port (to a Web server,for example) are passed through by a
          packet-filtering firewall or router.

          A conservative approach, then, might be to minimize the
          number of incoming ports serviced (N), then set SOMAXCONN so
          that

             N * SOMAXCONN < 1000

          Since each queue entry consumes about 600 bytes of memory,
          the total amount of memory dedicated to queue entries when
          the system was under attack would then be 600,000--more than
          one-fourth the total mbuf allocation.

          a. Change the maximum per-port backlog queue value parameter,
          SOMAXCONN, and rebuild the kernel. The parameter is defined
          in the header file /sys/sys/socket.h.

          b. Place the value in a variable, so that it can easily be
          changed with adb. This more flexible approach is the one we
          expect to take in an upcoming 4.1.x kernel patch.

          Here are diff files (again from 4.1.4) showing one way to
          effect that change.

             uipc_socket.c:
             > /* adjustable variable to replace SOMAXCONN */
             > int somaxconn = SOMAXCONN;
             >
             119c122
             <       so->so_qlimit = MIN(backlog, SOMAXCONN);
             ---
             >       so->so_qlimit = MIN(backlog, somaxconn);


          After editing the files, you would need to put the modified
          uipc_socket.c in /sys/os and the modified tcp_input.c in
          /sys/netinet and rebuild a kernel.

          Note that since so_qlimit (the receive queue limit) is the
          MIN() of the application-specified backlog value and
          somaxconn, listening applications must be restarted after a
          change to the new variable somaxconn is made.

          c. Modify the kernel code which uses SOMAXCONN, causing it
          to disregard the application-specified backlog and substitute
          the same (presumably higher) value for each port. We have
          not tested this approach under production conditions and
          stop short, at this point, of recommending it.

             uipc_socket.c:
             > /* adjustable variable to replace SOMAXCONN */
             > int somaxconn = SOMAXCONN;
             >
             119c122
             <       so->so_qlimit = MIN(backlog, SOMAXCONN);
             ---
             >       so->so_qlimit = somaxconn; /* NOT RECOMMENDED */

    C. Increasing the Number of Connections the Listener Processes Can Service

       As stated earlier, increasing the length of the backlog queue
       will have no effect unless you also make an adjustment involving
       the listen() call on the affected port(s). That is, listening
       applications will need to be rebuilt to increase the requested
       backlog value, so that the new SOMAXCONN value is reflected in
       so_qlimit.

       Three listening applications found on most UNIX systems are
       in.named, sendmail, and inetd. (Many sites also run their own
       customer applications.) So one example of a listener program
       which will need to be changed is inetd, which issues the
       listen() call on behalf of the daemons for which it watches
       ports.

       We expect to issue a patch for inetd in the near future (see
       section IV.D). That patch is likely to add to inetd the ability
       to specify on the command line the number of connections to
       which inetd will listen on a particular port.

       Until such a patch is available, customers with source licenses
       may want to rebuild inetd, implementing either the new feature
       described above or the following, simpler change. The change
       is once again shown with reference to SunOS 4.1.4 source.

             inetd.c:
             656c656
             <               listen(sep->se_fd, 10);
             ---
             >               listen(sep->se_fd, 1000000);
             705c705
             <               listen(sep->se_fd, 10);
             ---
             >               listen(sep->se_fd, 1000000);
             1247c1276
             <                       qlen = 10;
             ---
             >                       qlen = 1000000;
             1324c1353
             <                       listen(sep->se_fd, 10);
             ---
             >                       listen(sep->se_fd, 1000000);
             1365c1394
             <                       qlen = 10;
             ---
             >                       qlen = 1000000;
             1433c1462
             <               listen(sep->se_fd, 10);
             ---
             >               listen(sep->se_fd, 1000000);

       The effect of these edits would be to cause inetd to always
       specify in the listen() call that it could handle 1,000,000
       simultaneous connections. The effective value would thus be
       the system's upper limit.


IV.  Plans and Schedules

The parametric adjustments we have discussed can bring about
significant improvement. But they do not represent a complete solution
to the problems posed by the SYN flood attack.  The principal drawbacks
are:

1. Lowering the abort timer value to small values (on the order of ten
seconds) is not practical when slow asynchronous lines must be
serviced. Service providers may find this dilemma particularly
difficult to resolve--unless all access to their systems is via slow
lines, in which case the attack rate will be low, and long timeouts
values may be acceptable.

2. Increasing the backlog queue to very large (on the order of 10K)
means that, when the system is under attack, falsified requests will
consume several megabytes of memory. This memory, and the CPU cycles
needed to handle the requests and operate the timeouts, are resources
wasted when the system must treat every request in the same way.

3. Modifying system parameters to allow a larger maximum backlog queue
length has no effect without other changes. The kernel will only insert
into a port's queue however many connection requests the servicing
application announced it could handle at the time it issued the
listen() system call. In some applications, the listen backlog size is
configurable. In others, the size is hard-coded. Unfortunately, for
inetd (a program which itself serves as a listener on behalf of other
programs) the value used for the backlog size is hard-coded. So inetd
must be re-compiled in order for a change in the system maximum to have
any effect on ports on which inetd is listening.

Better solutions require algorithmic re-design at the source level.

    A. Design-Level Changes Being Considered

       Sun is currently testing several possible new algorithms to deal
       with SYN flood and similar attacks. Many of these possible
       changes were suggested and analyzed in the informal discussions
       that have arisen amongst experts worldwide seeking defensive
       countermeasures.

       Some of the methods being considered for inclusion in some
       Solaris/SunOS releases are:

       1. Implement an algorithm (perhaps a combination of "random
          drop" and "oldest drop") to drop queue members when the backlog
          queue is full.

       2. Tune the networking code to handle large numbers of SYN
          requests more efficiently by (for example) changing the
          listener queue to use more efficient data structures, such as
          hash tables.

       3. Give priority to requests which originate from sources
          with which successful handshakes have already been concluded
          in the past.

       In addition, many of the above methods might be combined with an
       adaptive approach to produce behavior which varies depending on
       whether or not the system seems to be under attack.

    B. OS Versions For Which Algorithmic Changes Are Being Developed

       Sun will develop and adopt defensive techniques, similar to
       those outlined above, in a future release of Solaris/SunOS. Some
       of these techniques are already being tested in our development
       labs for possible inclusion in the next release.

       In addition, Sun commits to producing patches representing an
       appropriate subset of such techniques for the following versions
       of Solaris/SunOS: Solaris 2.5.1, 2.5, and 2.4 (SunOS 5.5.1, 5.5,
       and 5.4 respectively). Patches will be supplied for all
       supported hardware platforms.

    C. OS Versions For Which No Algorithmic Changes Are Planned

       No design-level algorithmic changes are planned for the
       following versions of Solaris/SunOS: 5.3 (Solaris 2.3), 4.1.4,
       4.1.3_U1, and 4.1.3. This decision was reached after careful
       study of several engineering options and their concomitant
       benefits, resource commitments, and risks.

       Sun will produce patches for these releases in the near future,
       however, which make it possible for customers without source
       code to implement the parametric adjustments described in the
       Technical Recommendations section.

       We also encourage all customers who may be affected by this new
       attack to investigate third-party solutions such as those
       alluded to earlier.

       Note that the SYN flood attack is not the result of any system
       bug, defect, or flaw, nor any error in implementing the TCP
       protocol.  Rather, it represents the stark difference between
       the world in which TCP was designed and the Internet environ-
       ment we work in and live in today. The decision to not develop
       algorithmic changes for these older releases does not represent
       any change in Sun's commitment to provide fixes, free of charge,
       for all security bugs in supported releases.

    D. Schedule of Upcoming Patches

       Sun will produce patches in the near future to facilitate the
       application of parametric changes to SunOS 4.1.x systems.  We
       expect that these patches, which will appply to the kernel and
       to inetd, will be available in two weeks or less.

       Sun will also produce inetd patches for all supported Solaris
       2.x releases.  We expect these patches to be available within
       three weeks.

       As described earlier, Sun will also release kernel patches for
       Solaris 2.4 and later releases which implement design-level
       changes. We will give these changes an extremely high priority
       in the development and patch processes. Official patches may
       take as long as two or even three months to produce, as a result
       of the testing required of every kernel patch; but preliminary
       patches should be available within 30 days for testing by
       interested customers.

       All of the patches described above will be announced via our
       usual methods. In addition, we will issue within 30 days a
       supplemental Sun Bulletin detailing the algorithms we have
       selected and the exact dates we expect the patches to be
       available.


APPENDICES

A.   Queuing Capacity Vs. Attack Rates

    1. The arithmetical relationships

    The relationship between the effects of queue length, abort timeout,
    and available memory is shown by the following calculations. Each
    entry in the backlog queue takes up roughly 600 bytes. Let:

       T = the setting of the abort timer, in seconds;
       L = the backlog limit of the listener queue, per port, in bytes;
       N = the number of ports which must service SYN connections;
       R = the rate of all incoming SYN requests on a given port; and
       RTT = Round-trip-time between the client and the server.

    Then we can calculate the total amount of memory potentially consumed by
    a full-out SYN attack on all ports, filling all queues, as:

       N * L * ~600

    So the total for, say, 25 ports with queues 8,192 entries long would be

       25 ports  *  8,192 entries  *  ~600  bytes/entry

    or about 120MB. This calculation shows why an increase from 64 MB to
    128 MB may help your system cope with an attack, and also why it is
    important to determine and reduce the number of listening ports.

    2. Memory limits

    On Solaris 2.x systems, the memory the system allocates to the
    queues comes from the kernel heap. Adding physical memory beyond 64
    MB may not increase the size of the heap, which is itself allocated
    from the virtual address space available to the kernel. The maximum
    memory available to the kernel varies depending on the hardware
    platform.  Some common values are 100MB for sun4m machines,
    240-250MB for sun4d machines, and more than 2GB for sun4u
    processors.

    On SunOS 1.x systems, of course, the allocation must come from the
    2MB mbuf limit.

    3. Queue overflow and timeouts

    If a port is under attack, and the queue is filling up, then all
    incoming SYN requests (good or faked) will continue to be queued so
    long as

       L/T > R

    When the SYN arriving rate R is greater than L/T, however, then
    R - L/T packets/sec will be dropped. At that point, therefore,
    a legitimate SYN request may be lost in the flood of fakes.

    Of course, for any request, if RTT > T, the request will time out.

B.   How to obtain Sun security patches

    1. If you have a support contract

    Customers with Sun support contracts can obtain any patches listed
    in this bulletin (and any other patches--and a list of patches)
    from:

       - SunSolve Online
       - Local Sun answer centers, worldwide
       - SunSITEs worldwide

    The patches are available via World Wide Web at
    http://sunsolve1.sun.com.

    You should also contact your answer center if you have a support
    contract and:

       - You need assistance in installing a patch
       - You need additional patches
       - You want an existing patch ported to another platform
       - You believe you have encountered a bug in a Sun patch
       - You want to know if a patch exists, or when one will be ready

    2. If you do not have a support contract

    Customers without support contracts may now obtain security
    patches, "recommended" patches, and patch lists via SunSolve
    Online.

    Sun does not furnish patches to any external distribution sites
    other than the ones mentioned here. The ftp.uu.net and ftp.eu.net
    sites are no longer supported.

    3. About the checksums

    So that you can quickly verify the integrity of the patch files
    themselves, we supply in each bulletin checksums for the tar
    archives.

    Occasionally, you may find that the listed checksums do not match
    the patches on the SunSolve or SunSite database. This does not
    necessarily mean that the patch has been tampered with. More
    likely, a non-substantive change (such as a revision to the README
    file) has altered the checksum of the tar file. The SunSolve patch
    database is refreshed nightly, and will sometimes contain versions
    of a patch newer than the one on which the checksums were based.

    In the future we may provide checksum information for the
    individual components of a patch as well as the compressed archive
    file. This would allow customers to determine, if need be, which
    file(s) have been changed since we issued the bulletin containing
    the checksums.

    In the meantime, if you would like assistance in verifying the
    integrity of a patch file please contact this office or your local
    answer center.


C.   How to report or inquire about Sun security problems

If you discover a security problem with Sun software or wish to inquire
about a possible problem, contact one or more of the following:

   - Your local Sun answer centers
   - Your representative computer security response team, such as CERT
   - This office. Address postal mail to:

         Sun Security Coordinator
         MS MPK17-103
         2550 Garcia Avenue
         Mountain View, CA 94043-1100

         Phone: 415-786-5274
         Fax:   415-786-7994
         E-mail: security-alert@Sun.COM

We strongly recommend that you report problems to your local Answer
Center. In some cases they will accept a report of a security bug even
if you do not have a support contract. An additional notification to
the security-alert alias is suggested but should not be used as your
primary vehicle for reporting a bug.


D.   How to obtain Sun security bulletins or short status updates

    1. Subscription information

    Sun Security Bulletins are available free of charge as part of our
    Customer Warning System. It is not necessary to have a Sun support
    contract in order to receive them.

    To receive information or to subscribe or unsubscribe from our
    mailing list, send mail to security-alert@sun.com with a subject
    line containing one of the following commands.


        Subject         Information Returned/Action Taken
        -------         ---------------------------------

        HELP            An explanation of how to get information

        LIST            A list of current security topics

        QUERY [topic]   The mail containing the question is relayed to
                        a Security Coordinator for a response.

        REPORT [topic]  The mail containing the text is treated as a
                        security bug report and forwarded to a Security
                        Coordinator for handling. Please note that this
                        channel of communications does not supersede
                        the use of Sun Solution Centers for this
                        purpose.  Note also that we do not recommend
                        that detailed problem descriptions be sent in
                        plain text.

        SEND topic      Summary of the status of selected topic. (To
                        retrieve a Sun Security Bulletin, supply the
                        number of the bulletin, as in "SEND #103".)

        SUBSCRIBE       Sender is added to the CWS (Customer
                        Warning System) list.  The subscribe feature
                        requires that the sender include on the subject
                        line the word "cws" and the reply email
                        address.  So the subject line might look like
                        the following:

                                SUBSCRIBE cws graff@sun.com

        UNSUBSCRIBE     Sender is removed from the CWS list.


    Should your email not fit into one of the above subjects, a help
    message will be returned to you.

    Due to the volume of subscription requests we receive, we cannot
    guarantee to acknowledge requests. Please contact this office if
    you wish to verify that your subscription request was received, or
    if you would like your bulletin delivered via postal mail or fax.

    2. Obtaining old bulletins

    Sun Security Bulletins are available via the security-alert alias
    and on SunSolve. Please try these sources first before contacting
    this office for old bulletins.

                                ------------