-----BEGIN PGP SIGNED MESSAGE-----



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

FreeBSD-SA-00:52                                           Security Advisory

                                                                FreeBSD, Inc.



Topic:          TCP uses weak initial sequence numbers



Category:       core

Module:         kernel

Announced:      2000-10-06

Credits:        Hacker Emergency Response Team 

Affects:        FreeBSD 3.x, 4.x and 5.x prior to the correction date

Corrected:      2000-09-28 (5.0-CURRENT, 4.1.1-STABLE, 3.5.1-STABLE)

FreeBSD only:   NO



I.   Background



TCP network connections use an initial sequence number as part of the

connection handshaking. According to the TCP protocol, an

acknowledgement packet from a remote host with the correct sequence

number is trusted to come from the remote system with which an

incoming connection is being established, and the connection is

established.



II.  Problem Description



It has long been known that an attacker who can guess the initial

sequence number which a system will use for the next incoming TCP

connection can spoof a TCP connection handshake coming from a machine

to which he does not have access, and then send arbitrary data into

the resulting TCP connection which will be accepted by the server as

coming from the spoofed machine.



Systems derived from 4.4BSD-Lite2 including FreeBSD include code which

attempts to introduce an element of unpredictability into the initial

sequence numbers to prevent sequence number guessing by a remote

attacker. However 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.



In order for this to be successfully exploited, the attacker must also

satisfy the following conditions:



a) be able to initiate several consecutive TCP connections to an open

port on the server in a short space of time (immediately followed by

the attack itself). Quiescent servers (those which are not receiving

connections from other systems at the time of attack) are therefore

most vulnerable to the attack.



b) be able to prevent the spoofed client machine from responding to

the packets sent to it from the server, by making use of an address

which is offline or by executing a denial of service attack against

it to prevent it from responding.



c) make use of an application-level protocol on the server which

authenticates or grants trust solely based on the IP address of the

client, not any higher-level authentication mechanisms such as a

password or cryptographic key.



d) be able to guess or infer the return TCP data from the server to

the spoofed client (if any), to which he will not have access,



All versions of FreeBSD prior to the correction date including 4.1.1

and 3.5.1 are vulnerable to this problem.



The FreeBSD Security Officer would like to thank the Hacker Emergency

Response Team for working with us to bring this matter to our

attention, and to coordinate the release of this advisory.



III. Impact



Systems running insecure protocols which blindly trust a TCP

connection which appears to come from a given IP address without

requiring other authentication of the originator are vulnerable to

spoofing by a remote attacker, potentially yielding privileges or

access on the local system.



Examples of such protcols and services are: the rlogin/rsh/rexec

family when used to grant passwordless access (e.g. via .rhosts or

hosts.equiv files); web server address-based access controls on

scripts which do not require user authentication and which control

privileged resources; tcp-wrappers host access controls around

services which do not authenticate the connection further; lpr

address-based access controls, and others.



Note that the rlogin family of protocols when configured to use

Kerberos or UNIX passwords are not vulnerable to this attack since

they authenticate connections (using Kerberos tickets in the former

case, and account passwords in the latter). Source address based

authentication in the rlogin family of protocols is not used by

default, and must be specifically enabled through use of a per-user

.rhosts file, or a global /etc/hosts.equiv file.



Attackers can also forge TCP connections to arbitrary TCP protocols

(including protocols not vulnerable to the spoofing attack described

above) and simulate the effects of failed remote access attempts from

a target machine (e.g. repeated attempts to guess a password),

potentially misleading the administrators of the server into thinking

they are under attack from the spoofed client.



IV.  Workaround



Note that in order to exploit the vulnerability an attacker must make

several real connection attempts in close succession to a port on the

target machine (e.g. a web server). Since in order for the attack to

be successful the machine must be quiescent (i.e. not accepting any

other connections), this rapid connection activity followed by a

connection to an insecure service may provide a signature which can be

used to detect and trace the attacker.



Possible workarounds for the vulnerability include one or both of the

following:



1) Disable all insecure protocols and services including rlogin, rsh

and rexec (if configured to use address-based authentication), or

reconfigure them to not authenticate connections based solely on

originating address. In general, the rlogin family should not be used

anyway - the ssh family of commands (ssh, scp, slogin) provide a

secure alternative which is included in FreeBSD 4.0 and above.



To disable the rlogin family of protocols, make sure the

/etc/inetd.conf file does not contain any of the following entries

uncommented (i.e. if present in the inetd.conf file they should be

commented out as shown below:)



#shell   stream  tcp     nowait  root    /usr/libexec/rshd       rshd

#login   stream  tcp     nowait  root    /usr/libexec/rlogind    rlogind

#exec    stream  tcp     nowait  root    /usr/libexec/rexecd     rexecd



Be sure to restart inetd by sending it a HUP signal after making any

changes:



# kill -HUP `cat /var/run/inetd.pid`



Audit the use of other services including those noted in section III

above and either disable the service, or if possible require it to use

a stronger form of authentication. See workaround 3) below.



2) Impose IP-level packet filters on network perimeters or on local

affected machines to prevent access from any outside party to a

vulnerable internal service using a "privileged" source address. For

example, if machines on the internal 10.0.0.0/24 network are allowed

to obtain passwordless rlogin access to a server, then external users

should be prevented from sending packets with 10.0.0.0/24 source

addresses from the outside network into the internal network. This is

standard good security policy. Note however that if an external

address must be granted access to local resources then this type of

filtering cannot be applied. It also does not defend against spoofing

attacks from within the network perimeter. Consider disabling this

service until the affected machines can be patched.



3) Enable the use of IPSEC to authenticate (and/or encrypt) vulnerable

TCP connections at the IP layer. A system which requires authenticaion

of all incoming connections to a port using IPSEC cannot be spoofed

using the attack described in this advisory, nor can TCP sessions be

hijacked by an attacker with access to the packet stream. FreeBSD 4.0

and later include IPSEC functionality in the kernel, and 4.1 and later

include an IKE daemon, racoon, in the ports collection. Configuration

of IPSEC is beyond the scope of this document, however see the

following web resources:



http://www.freebsd.org/handbook/ipsec.html

http://www.netbsd.org/Documentation/network/ipsec/

http://www.kame.net/



V.   Solution



Note that address-based authentication is generally weak, and should

be avoided even in environments running with the sequence numbering

improvements. Instead, cryptographically-protected protocols and

services should be used wherever possible.



One of the following:



1) Upgrade your vulnerable FreeBSD system to 4.1.1-STABLE or

3.5.1-STABLE after the respective correction dates.



2a) FreeBSD 3.x systems



Download the patch and detached PGP signature from the following

locations, and verify the signature using your PGP utility.



http://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:52/tcp-iss-3.x.patch

http://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:52/tcp-iss-3.x.patch.asc



# cd /usr/src/sys/

# patch -p < /path/to/patch



[ Recompile your kernel as described in

http://www.freebsd.org/handbook/kernelconfig.html and reboot the

system ]



2b) FreeBSD 4.x systems



Apply the patch below and recompile your kernel.



Either save this advisory to a file, or download the patch and

detached PGP signature from the following locations, and verify the

signature using your PGP utility.



http://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:52/tcp-iss.patch

http://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:52/tcp-iss.patch.asc



# 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 ]



Patch for vulnerable 4.x systems:



    Index: tcp_seq.h

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

    RCS file: /usr2/ncvs/src/sys/netinet/tcp_seq.h,v

    retrieving revision 1.11

    retrieving revision 1.12

    diff -u -r1.11 -r1.12

    --- tcp_seq.h 1999/12/29 04:41:02 1.11

    +++ tcp_seq.h 2000/09/29 01:37:19 1.12

    @@ -91,7 +91,7 @@

      * number in the range [0-0x3ffff] that is hard to predict.

      */

     #ifndef tcp_random18

    -#define tcp_random18() ((random() >> 14) & 0x3ffff)

    +#define tcp_random18() (arc4random() & 0x3ffff)

     #endif

     #define TCP_ISSINCR (122*1024 + tcp_random18())



    Index: tcp_subr.c

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

    RCS file: /usr2/ncvs/src/sys/netinet/tcp_subr.c,v

    retrieving revision 1.80

    retrieving revision 1.81

    diff -u -r1.80 -r1.81

    --- tcp_subr.c 2000/09/25 23:40:22 1.80

    +++ tcp_subr.c 2000/09/29 01:37:19 1.81

    @@ -178,7 +178,7 @@

     {

     int hashsize;

     

    - tcp_iss = random(); /* wrong, but better than a constant */

    + tcp_iss = arc4random(); /* wrong, but better than a constant */

     tcp_ccgen = 1;

     tcp_cleartaocache();



-----BEGIN PGP SIGNATURE-----

Version: 2.6.2



iQCVAwUBOd5Gv1UuHi5z0oilAQEzJwQAkJbKJBJcaIYFbMuRnINbNQQS/mLUuRoh

fIzPEC17B2fwx+NjuHppBXroOsmsw0enM4tk7afP2yc3z2Ecyapr+oQH9KzBQ+nQ

56IGoi5/MLgEY2KQn3kQBV++pH9zo/F/Gz3XV/x2gDUgLy0F9p2eYjDGkrA1U1H2

NTx5kXB6ZE4=

=zdbr

-----END PGP SIGNATURE-----