search menu icon-carat-right cmu-wordmark

CERT Coordination Center


Multiple TCP/IP implementations may use statistically predictable initial sequence numbers

Vulnerability Note VU#498440

Original Release Date: 2001-03-13 | Last Revised: 2015-10-21

Overview

Attacks against TCP initial sequence number generation have been discussed for some time now. It has long been recognized that the ability to know or predict ISNs can lead to TCP connection hijacking or spoofing. What was not previously illustrated was just how predictable one commonly-used method of randomizing new connection ISNs is in some modern TCP/IP implementations.

Description

The CERT/CC has received a report from Guardent, Inc. concerning an observed statistical weakness in initial sequence number (ISN) generation for TCP connections. Guardent asserts in copyrighted research forwarded to us that incrementing the ISN by some series of pseudo-random amounts is insufficient to protect some TCP implementations from a practical ISN guessing attack in some real-world situations. Such attacks would not rely on data collected (sniffed) from a a victim site. These observations and statistical analyses provide empirical data which draw attention to the protocol analysis documented by Steve Bellovin (building on work pioneered by Robert Morris), culminating in RFC1948.

In RFC1948, Steve noted:

   The initial sequence numbers are intended to be more or less random.
   More precisely, RFC 793 specifies that the 32-bit counter be
   incremented by 1 in the low-order position about every 4
   microseconds.  Instead, Berkeley-derived kernels increment it by a
   constant every second, and by another constant for each new
   connection.  Thus, if you open a connection to a machine, you know to
   a very high degree of confidence what sequence number it will use for
   its next connection.  And therein lies the attack.

Some TCP/IP implementors chose instead to increment the ISNs using constrained random variables instead of constants. Guardent's research demonstrates that the algorithm implemented in some of these TCP/IP stacks is statistically weak and susceptible to attack.

We are currently soliciting feedback from the vendor community to help us understand the scope of this observed statistical weakness. Guardent's work has drawn attention to the fact that not all current TCP/IP stack implementations have implemented RFC1948 or provided an equivalent fix.

As of 2015, predictable TCP ISN generation is still somewhat common, particularly in low-power/low-bandwidth, embedded, and IoT devices that use older operating systems and networking code.

Impact

If the ISN of an existing connection can be determined within some practical range, a malicious agent may be able to close or hijack the connection. If the ISNs of future connections are targeted, an agent may be able to "complete" a TCP three-way handshake and spoof TCP packets delivered to a victim.

Solution

Deploy IPsec.

Implement the suggestions in RFC1948, namely the segmentation of the ISN space on a per-host, per-connection basis using cryptographic hashed secrets.

Vendor Information

498440
Expand all

Beckwith Electric

Updated:  October 20, 2015

Status

  Affected

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Addendum

Please see ICS-CERT Advisory ICSA-15-153-01.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

FreeBSD, Inc.

Notified:  March 08, 2001 Updated:  September 12, 2002

Status

  Vulnerable

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Fujitsu

Notified:  March 08, 2001 Updated:  April 22, 2001

Statement Date:   April 20, 2001

Status

  Vulnerable

Vendor Statement

Hi.  Fujitsu is currently working on the patches for the UXP/V
operating system to address the vulnerabilities reported in VU#498440.

The patches will be made available with the following ID numbers:

  OS Version,PTF level    patch ID
 --------------------    --------
  UXP/V V20L10 X01021    UX28164
  UXP/V V20L10 X00091    UX28163
  UXP/V V10L20 X01041    UX15529

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Hewlett-Packard Company

Notified:  March 08, 2001 Updated:  September 12, 2002

Statement Date:   August 30, 2002

Status

  Vulnerable

Vendor Statement

Current statement PGP Signed: 8/29/2002 8:51:54 PM

====================================================

The following tcp randomizations are now available:

        HP-UX releases 11.00, 11.04, and 11.11 (11i):
             - HP randomization
             - RFC 1948 ISN randomization


        For HP randomization on releases:
           HP-UX 11.00:       PHNE_22397 or subsequent,
           HP-UX 11.11:       default mode.

         For RFC 1948 ISN randomization
           HP-UX 11.00:       PHNE_26771 or subsequent,
           HP-UX 11.04:       PHNE_26101 or subsequent,
           HP-UX 11.11:       PHNE_25644 or subsequent.



 To enable tcp randomization on HP-UX 11.00, 11.04, and 11.11(11i):

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

  HP randomization

     HP-UX release 11.00:
    Install PHNE_22397 or subsequent.  The HP randomization will
    then be the default tcp randomization.

       NOTE: This patch has dependencies.


     HP-UX release 11.11 (11i):
    No patch is required.  The HP randomization has always been
    implemented in HP-UX 11.11 (11i) and is the default tcp
    randomization.

  RFC 1948 ISN randomization

     HP-UX 11.00:       Apply PHNE_26771 or subsequent.
    HP-UX 11.04:       Apply PHNE_26101 or subsequent.
    HP-UX 11.11 (11i): Apply PHNE_25644 or subsequent.

     Once the appropriate patch has been applied the RFC 1948 ISN
    randomization can be enabled on HP-UX 11.00, 11.04 and 11.11
    by executing the following command as root:

         ndd -set /dev/tcp tcp_isn_passphrase <secret passphrase>
             where <secret passphrase> is any length character
             string.  Only the first 32 characters will be
             retained.  If the passphrase is changed the system
             should be rebooted.

     NOTE: RFC 1948 ISN randomization is not available on
          HP-UX release 10.20.  Customers who want RFC 1948
          ISN randomization should upgrade to HP-UX 11.X and
          apply necessary patches as discussed herein.



For the the legacy 10.20 release:
- ---------------------------------

  HP created a tunable kernel parameter that can enable two levels of
 randomization.    This randomization feature requires a TRANSPORT
patch
 level of:

  For S700 platform:  PHNE_17096 or greater
 For S800 platform:  PHNE_17097 or greater

  The tunable kernel parameter is set as follows using the "nettune"
program:

    tcp_random_seq set to 0  (Standard TCP sequencing)
   tcp_random_seq set to 1  (Random TCP sequencing)
   tcp_random_seq set to 2  (Increased Random TCP sequencing)

  and requires a reboot.
- --

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Addendum

Previous statement issued 05/01/2001:

HP has been tracking tcp randomization issues over the years, and has to date implemented the following:

             For 11.00 and 11.11 (11i):
             _______________________________

             For 11.00, if you want HP's solution for randomized ISN numbers then apply TRANSPORT patch PHNE_22397. Once you apply PHNE_22397, there's nothing more to do --- default is randomized ISNs.

             (Note: PHNE_22397 has patch dependencies unrelated to ISN randomized ISN number modification listed in the dependency section, but they should still be also applied. One is a PHKL kernel patch dependency and the other STREAMS/UX minimum level patch dependency.)

             The LR release of 11.11 (11i) has the same random ISN implementation as the patched 11.00.

             For the the legacy 10.20 release
             __________________________________

             HP created a tunable kernel parameter that can enable two levels of randomization. This randomization feature requires a TRANSPORT patch level of:


             For S700 platform:  PHNE_17096 or greater
             For S800 platform:  PHNE_17097 or greater

             The tunable kernel parameter is set as follows using the "nettune" program:

                     tcp_random_seq set to 0  (Standard TCP sequencing)
                     tcp_random_seq set to 1  (Random TCP sequencing)
                     tcp_random_seq set to 2  (Increased Random TCP sequencing)

             and requires a reboot.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

OpenBSD

Notified:  March 08, 2001 Updated:  April 19, 2001

Statement Date:   March 08, 2001

Status

  Vulnerable

Vendor Statement

post-2.8 we no longer use random increments, but a much more sophisticated
way.,

please note that using real random initial sequence numbers is pretty
much in violation of the RFC's, since random number generators are
totally allowed to provide a number like 42 three times in a row.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

SGI

Updated:  March 20, 2002

Statement Date:   April 25, 2001

Status

  Vulnerable

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Addendum

SGI has released security advisory 20020303-01-A regarding this issue.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Sun Microsystems, Inc.

Notified:  March 08, 2001 Updated:  September 12, 2002

Status

  Vulnerable

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Wind River

Updated:  October 20, 2015

Status

  Affected

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Addendum

Multiple versions of VxWorks generate TCP ISNs in a predictable way. For more information, see ICS-CERT Advisory ICSA-15-169-01. Wind River, sometimes called Wind River Systems, is a wholly owned subsidiary of Intel. VxWorks is used in many OEM products, including Schneider Electric control systems equipment.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

IBM Corporation

Notified:  March 08, 2001 Updated:  April 19, 2001

Statement Date:   April 12, 2001

Status

  Not Vulnerable

Vendor Statement

We have studied the document written by Guardent regarding vulnerabilities
caused by statistical analysis of random increments, that may allow a
malicious user to predict the next sequence of chosen TCP connections.

IBM's AIX operating system should not be vulnerable as we have implemented
RFC 1948 in our source coding. According to Guardent, we do not expect an
exploit described in the document to affect our AIX OS because we employ
RFC 1948.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Apple Computer, Inc.

Notified:  March 08, 2001 Updated:  September 12, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Berkeley Software Design, Inc.

Notified:  March 08, 2001 Updated:  September 12, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Cisco Systems, Inc.

Notified:  March 08, 2001 Updated:  September 12, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Data General

Notified:  March 08, 2001 Updated:  September 12, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Microsoft Corporation

Notified:  March 08, 2001 Updated:  September 12, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

NeXT

Notified:  March 08, 2001 Updated:  September 12, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

NetBSD

Notified:  March 08, 2001 Updated:  September 12, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.

Red Hat, Inc.

Notified:  March 08, 2001 Updated:  September 12, 2002

Status

  Unknown

Vendor Statement

No statement is currently available from the vendor regarding this vulnerability.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us email.


CVSS Metrics

Group Score Vector
Base 5.8 AV:N/AC:M/Au:N/C:P/I:N/A:P
Temporal 4.8 E:F/RL:OF/RC:C
Environmental 3.6 CDP:ND/TD:M/CR:ND/IR:ND/AR:ND

References

Credit

The CERT/CC thanks the following individuals and organizations for their contributions to this advisory: Steve Bellovin , AT&T Labs Tim Newsham Guardent , Inc. BindView Niels Provohs

This document was written by Jeffrey S. Havrilla.

Other Information

CVE IDs: CVE-2001-0328
CERT Advisory: CA-2001-09
Severity Metric: 15.19
Date Public: 2001-03-12
Date First Published: 2001-03-13
Date Last Updated: 2015-10-21 03:06 UTC
Document Revision: 82

Sponsored by the Department of Homeland Security Office of Cybersecurity and Communications.