3571e53040
patches for easier mirroring, to eliminate a special copy, to make www.freebsd.org/security a full copy of security.freebsd.org and be eventually be the same. For now files are just sitting there. The symlinks are missing. Discussed on: www (repository location) Discussed with: simon (so)
258 lines
11 KiB
Text
258 lines
11 KiB
Text
-----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-----
|