BSD Weak initial Sequence Number Vulnerability
BID:1766
Info
BSD Weak initial Sequence Number Vulnerability
| Bugtraq ID: | 1766 |
| Class: | Design Error |
| CVE: |
CVE-2000-0916 |
| Remote: | Yes |
| Local: | No |
| Published: | Oct 05 2000 12:00AM |
| Updated: | Jul 11 2009 03:56AM |
| Credit: | First published in HERT advisory #00003 posted to Bugtraq by Pascal Bouchareine <[email protected]>. |
| Vulnerable: |
FreeBSD FreeBSD 4.1.1 FreeBSD FreeBSD 4.1 FreeBSD FreeBSD 4.0 FreeBSD FreeBSD 3.x FreeBSD FreeBSD 2.x |
| Not Vulnerable: | |
Discussion
BSD Weak initial Sequence Number Vulnerability
During the TCP three-way handshake (connection initiation), the host to which the connection request was sent is responsible for generation of the "initial TCP sequence number". This number is used to verify that the final part of the connection initiation (final ACK) is completed by the correct host (ie, only the host that originally made the request should respond with that sequence number + 1).
Traditionally, remote (outside of LAN) TCP connection spoofing has been possible due to guessable initial sequence numbers. Their predictability is a result of their generation algorithms. 4.4BSD-Lite2 and derived operating systems (such as FreeBSD) contain code that attempts to add "randomness" to the generation of initial sequence numbers. Unfortunately the initial sequence numbers generated by vulnerable BSD-based operating systems are predictable if certain circumstances are met. To quote the FreeBSD advisory on this issue,
"the pseudo-random number generator used is a simple linear congruent generator , and based on observations of a few initial sequence values from legitimate connections with a server, an attacker can guess with high probability the value which will be used for the next connection."
If an attacker can watch several legitimate connections establish between his host and the target, it becomes possible to anticipate future initial sequence numbers. With this capability, an attacker can carry out attacks against host address based authentication on the victim server. However, in order to successfully exploit this, the host being spoofed must be down or non-responsive to SYN-ACKs it does not expect to recieve. There must also be a service or application in use on the target server that uses only host address authentication (which is what would be made vulnerable by spoofing..)
An example of how this can be exploited, in conjunction with an application that uses host-address based authentication is as follows:
Berkeley "r-services": If a victim is running these services and .rhosts authentication is in use, it may be possible for an attacker to use this vulnerability to spoof connections from trusted hosts (which will not require authentication..). The address used (spoofed) would have to be that of a host trusted by the user and in their .rhosts file. It would also have to be down or non-responsive, something the attacker could accomplish with a denial of service attack. If successful, the hacker could add a host under his control to the victim users' .rhosts file, allowing him to login unauthenticated (via password) with a legitimate (and non-blind) tcp connection.
FreeBSD is confirmed as being vulnerable, it is not verified whether other BSDs are or not.
During the TCP three-way handshake (connection initiation), the host to which the connection request was sent is responsible for generation of the "initial TCP sequence number". This number is used to verify that the final part of the connection initiation (final ACK) is completed by the correct host (ie, only the host that originally made the request should respond with that sequence number + 1).
Traditionally, remote (outside of LAN) TCP connection spoofing has been possible due to guessable initial sequence numbers. Their predictability is a result of their generation algorithms. 4.4BSD-Lite2 and derived operating systems (such as FreeBSD) contain code that attempts to add "randomness" to the generation of initial sequence numbers. Unfortunately the initial sequence numbers generated by vulnerable BSD-based operating systems are predictable if certain circumstances are met. To quote the FreeBSD advisory on this issue,
"the pseudo-random number generator used is a simple linear congruent generator , and based on observations of a few initial sequence values from legitimate connections with a server, an attacker can guess with high probability the value which will be used for the next connection."
If an attacker can watch several legitimate connections establish between his host and the target, it becomes possible to anticipate future initial sequence numbers. With this capability, an attacker can carry out attacks against host address based authentication on the victim server. However, in order to successfully exploit this, the host being spoofed must be down or non-responsive to SYN-ACKs it does not expect to recieve. There must also be a service or application in use on the target server that uses only host address authentication (which is what would be made vulnerable by spoofing..)
An example of how this can be exploited, in conjunction with an application that uses host-address based authentication is as follows:
Berkeley "r-services": If a victim is running these services and .rhosts authentication is in use, it may be possible for an attacker to use this vulnerability to spoof connections from trusted hosts (which will not require authentication..). The address used (spoofed) would have to be that of a host trusted by the user and in their .rhosts file. It would also have to be down or non-responsive, something the attacker could accomplish with a denial of service attack. If successful, the hacker could add a host under his control to the victim users' .rhosts file, allowing him to login unauthenticated (via password) with a legitimate (and non-blind) tcp connection.
FreeBSD is confirmed as being vulnerable, it is not verified whether other BSDs are or not.
Exploit / POC
BSD Weak initial Sequence Number Vulnerability
x
x
Solution / Fix
BSD Weak initial Sequence Number Vulnerability
Solution:
FreeBSD has corrected the problem and released patches for 4.x and 3.x versions.
FreeBSD FreeBSD 3.x
FreeBSD FreeBSD 4.0
FreeBSD FreeBSD 4.1
FreeBSD FreeBSD 4.1.1
Solution:
FreeBSD has corrected the problem and released patches for 4.x and 3.x versions.
FreeBSD FreeBSD 3.x
-
FreeBSD 3.x tcp-iss-3.x.patch
# cd /usr/src/sys/netinet# patch -p < /path/to/patch_or_advisory[ Recompile your kernel as described in http://www.freebsd.org/handbook/kernelconfig.html and reboot the system ]
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:52/tcp-iss-3.x.pa tch
FreeBSD FreeBSD 4.0
-
FreeBSD 4.x tcp-iss.patch
# cd /usr/src/sys/netinet# patch -p < /path/to/patch_or_advisory[ Recompile your kernel as described in http://www.freebsd.org/handbook/kernelconfig.html and reboot the system ]
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:52/tcp-iss.patch
FreeBSD FreeBSD 4.1
-
FreeBSD 4.x tcp-iss.patch
# cd /usr/src/sys/netinet# patch -p < /path/to/patch_or_advisory[ Recompile your kernel as described in http://www.freebsd.org/handbook/kernelconfig.html and reboot the system ]
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:52/tcp-iss.patch
FreeBSD FreeBSD 4.1.1
-
FreeBSD 4.x tcp-iss.patch
# cd /usr/src/sys/netinet# patch -p < /path/to/patch_or_advisory[ Recompile your kernel as described in http://www.freebsd.org/handbook/kernelconfig.html and reboot the system ]
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:52/tcp-iss.patch