Lucene search

K
certCERTVU:498440
HistoryMar 13, 2001 - 12:00 a.m.

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

2001-03-1300:00:00
www.kb.cert.org
76

5 Medium

CVSS2

Access Vector

NETWORK

Access Complexity

LOW

Authentication

NONE

Confidentiality Impact

PARTIAL

Integrity Impact

NONE

Availability Impact

NONE

AV:N/AC:L/Au:N/C:P/I:N/A:N

0.029 Low

EPSS

Percentile

90.6%

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

Filter by status: All Affected Not Affected Unknown

Filter by content: __ Additional information available

__ Sort by: Status Alphabetical

Expand all

Javascript is disabled. Click here to view vendors.

Beckwith Electric __ Affected

Updated: October 20, 2015

Status

Affected

Vendor Statement

We have not received a statement from the vendor.

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](<mailto:[email protected]?Subject=VU%23498440 Feedback>).

FreeBSD, Inc. Affected

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

Status

Affected

Vendor Statement

We have not received a statement from the vendor.

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](<mailto:[email protected]?Subject=VU%23498440 Feedback>).

Fujitsu __ Affected

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

Statement Date: April 20, 2001

Status

Affected

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](<mailto:[email protected]?Subject=VU%23498440 Feedback>).

Hewlett-Packard Company __ Affected

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

Statement Date: August 30, 2002

Status

Affected

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 &lt;secret passphrase&gt; where &lt;secret passphrase&gt; 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](<mailto:[email protected]?Subject=VU%23498440 Feedback>).

OpenBSD __ Affected

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

Statement Date: March 08, 2001

Status

Affected

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](<mailto:[email protected]?Subject=VU%23498440 Feedback>).

SGI __ Affected

Updated: March 20, 2002

Statement Date: April 25, 2001

Status

Affected

Vendor Statement

We have not received a statement from the vendor.

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](<mailto:[email protected]?Subject=VU%23498440 Feedback>).

Sun Microsystems, Inc. Affected

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

Status

Affected

Vendor Statement

We have not received a statement from the vendor.

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](<mailto:[email protected]?Subject=VU%23498440 Feedback>).

Wind River __ Affected

Updated: October 20, 2015

Status

Affected

Vendor Statement

We have not received a statement from the vendor.

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](<mailto:[email protected]?Subject=VU%23498440 Feedback>).

IBM Corporation __ Not Affected

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

Statement Date: April 12, 2001

Status

Not Affected

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](<mailto:[email protected]?Subject=VU%23498440 Feedback>).

Apple Computer, Inc. Unknown

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

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

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](<mailto:[email protected]?Subject=VU%23498440 Feedback>).

Berkeley Software Design, Inc. Unknown

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

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

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](<mailto:[email protected]?Subject=VU%23498440 Feedback>).

Cisco Systems, Inc. Unknown

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

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

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](<mailto:[email protected]?Subject=VU%23498440 Feedback>).

Data General Unknown

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

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

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](<mailto:[email protected]?Subject=VU%23498440 Feedback>).

Microsoft Corporation Unknown

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

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

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](<mailto:[email protected]?Subject=VU%23498440 Feedback>).

NeXT Unknown

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

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

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](<mailto:[email protected]?Subject=VU%23498440 Feedback>).

NetBSD Unknown

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

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

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](<mailto:[email protected]?Subject=VU%23498440 Feedback>).

Red Hat, Inc. Unknown

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

Status

Unknown

Vendor Statement

We have not received a statement from the vendor.

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](<mailto:[email protected]?Subject=VU%23498440 Feedback>).

View all 17 vendors __View less vendors __

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

Acknowledgements

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

This document was written by Jeffrey S. Havrilla.

Other Information

CVE IDs: CVE-2001-0328
CERT Advisory: CA-2001-09 Severity Metric:

References

5 Medium

CVSS2

Access Vector

NETWORK

Access Complexity

LOW

Authentication

NONE

Confidentiality Impact

PARTIAL

Integrity Impact

NONE

Availability Impact

NONE

AV:N/AC:L/Au:N/C:P/I:N/A:N

0.029 Low

EPSS

Percentile

90.6%