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%
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.
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.
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.
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.
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.
Updated: October 20, 2015
Affected
We have not received a statement from the vendor.
We are not aware of further vendor information regarding this vulnerability.
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>).
Notified: March 08, 2001 Updated: September 12, 2002
Affected
We have not received a statement from the vendor.
We are not aware of further vendor information regarding this vulnerability.
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>).
Notified: March 08, 2001 Updated: April 22, 2001
Statement Date: April 20, 2001
Affected
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`
We are not aware of further vendor information regarding this vulnerability.
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>).
Notified: March 08, 2001 Updated: September 12, 2002
Statement Date: August 30, 2002
Affected
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):
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.
We are not aware of further vendor information regarding this vulnerability.
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>).
Notified: March 08, 2001 Updated: April 19, 2001
Statement Date: March 08, 2001
Affected
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.
We are not aware of further vendor information regarding this vulnerability.
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>).
Updated: March 20, 2002
Statement Date: April 25, 2001
Affected
We have not received a statement from the vendor.
We are not aware of further vendor information regarding this vulnerability.
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>).
Notified: March 08, 2001 Updated: September 12, 2002
Affected
We have not received a statement from the vendor.
We are not aware of further vendor information regarding this vulnerability.
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>).
Updated: October 20, 2015
Affected
We have not received a statement from the vendor.
We are not aware of further vendor information regarding this vulnerability.
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>).
Notified: March 08, 2001 Updated: April 19, 2001
Statement Date: April 12, 2001
Not Affected
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.
We are not aware of further vendor information regarding this vulnerability.
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>).
Notified: March 08, 2001 Updated: September 12, 2002
Unknown
We have not received a statement from the vendor.
We are not aware of further vendor information regarding this vulnerability.
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>).
Notified: March 08, 2001 Updated: September 12, 2002
Unknown
We have not received a statement from the vendor.
We are not aware of further vendor information regarding this vulnerability.
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>).
Notified: March 08, 2001 Updated: September 12, 2002
Unknown
We have not received a statement from the vendor.
We are not aware of further vendor information regarding this vulnerability.
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>).
Notified: March 08, 2001 Updated: September 12, 2002
Unknown
We have not received a statement from the vendor.
We are not aware of further vendor information regarding this vulnerability.
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>).
Notified: March 08, 2001 Updated: September 12, 2002
Unknown
We have not received a statement from the vendor.
We are not aware of further vendor information regarding this vulnerability.
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>).
Notified: March 08, 2001 Updated: September 12, 2002
Unknown
We have not received a statement from the vendor.
We are not aware of further vendor information regarding this vulnerability.
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>).
Notified: March 08, 2001 Updated: September 12, 2002
Unknown
We have not received a statement from the vendor.
We are not aware of further vendor information regarding this vulnerability.
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>).
Notified: March 08, 2001 Updated: September 12, 2002
Unknown
We have not received a statement from the vendor.
We are not aware of further vendor information regarding this vulnerability.
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 __
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 |
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.
CVE IDs: | CVE-2001-0328 |
---|---|
CERT Advisory: | CA-2001-09 Severity Metric: |
ftp://ftp.isi.edu/in-notes/rfc1323.txt
ftp://ftp.isi.edu/in-notes/rfc1750.txt
ftp://ftp.isi.edu/in-notes/rfc1948.txt
ftp://ftp.isi.edu/in-notes/rfc793.txt
ftp://research.att.com/dist/internet_security/117.ps.Z
ftp://research.att.com/dist/internet_security/ipext.ps.Z
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0077
cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2000-0328
lcamtuf.coredump.cx/newtcp/
lcamtuf.coredump.cx/oldtcp/
pdos.csail.mit.edu/~rtm/papers/117.pdf
www.cert.org/advisories/CA-1995-01.html
www.guardent.com/pr2001-03-12-ips.html
www.usenix.com/publications/library/proceedings/security95/full_papers/joncheray.txt
xforce.iss.net/static/139.php
cseweb.ucsd.edu/classes/sp99/cse227/ipext.pdf
ics-cert.us-cert.gov/advisories/ICSA-15-153-01
ics-cert.us-cert.gov/advisories/ICSA-15-169-01
www.cs.columbia.edu/~smb/papers/ipext.pdf
www.usenix.org/legacy/publications/library/proceedings/security95/full_papers/joncheray.txt