LinuxSecurity.com
Share your story
The central voice for Linux and Open Source security news
Home News Topics Advisories HOWTOs Features Newsletters About Register

Welcome!
Sign up!
EnGarde Community
Login
Polls
What is the most important Linux security technology?
 
Advisories
Community
Linux Events
Linux User Groups
Link to Us
Security Center
Book Reviews
Security Dictionary
Security Tips
SELinux
White Papers
Featured Blogs
All About Linux
DanWalsh LiveJournal
Securitydistro
Latest Newsletters
Linux Advisory Watch: December 19th, 2014
Linux Advisory Watch: December 12th, 2014
Subscribe
LinuxSecurity Newsletters
E-mail:
Choose Lists:
About our Newsletters
RSS Feeds
Get the LinuxSecurity news you want faster with RSS
Powered By

  
FreeBSD: TCP sequence number predication weakness Print E-mail
User Rating:      How can I rate this item?
Posted by LinuxSecurity.com Team   
FreeBSD TCP uses weak initial sequence numbers

-----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 <hert@hert.org>
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.
 
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:52/tcp-iss-3.x.patch 
ftp://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.
 
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:52/tcp-iss.patch 
ftp://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-----




 
< Prev   Next >
    
Partner

 

Latest Features
Peter Smith Releases Linux Network Security Online
Securing a Linux Web Server
Password guessing with Medusa 2.0
Password guessing as an attack vector
Squid and Digest Authentication
Squid and Basic Authentication
Demystifying the Chinese Hacking Industry: Earning 6 Million a Night
Free Online security course (LearnSIA) - A Call for Help
What You Need to Know About Linux Rootkits
Review: A Practical Guide to Fedora and Red Hat Enterprise Linux - Fifth Edition
Yesterday's Edition
Report: U.S. planning “proportional response” to Sony hack, blamed on North Korea
Heartbleed, Shellshock, Tor and more: The 13 biggest security stories of 2014
Partner Sponsor

Community | HOWTOs | Blogs | Features | Book Reviews | Networking
 Security Projects |  Latest News |  Newsletters |  SELinux |  Privacy |  Home
 Hardening |   About Us |   Advertise |   Legal Notice |   RSS |   Guardian Digital
(c)Copyright 2014 Guardian Digital, Inc. All rights reserved.