Date: Wed, 2 May 2001 14:20:01 -0700 (PDT) From: FreeBSD Security Advisories <security-advisories@FreeBSD.org> To: FreeBSD Security Advisories <security-advisories@FreeBSD.org> Subject: FreeBSD Security Advisory FreeBSD-SA-01:39.tcp-isn Message-ID: <200105022120.f42LK1386574@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
FreeBSD-SA-01:39 Security Advisory
FreeBSD, Inc.
Topic: TCP initial sequence number generation contains
statistical vulnerability
Category: core
Module: kernel
Announced: 2001-05-02
Credits: Tim Newsham <tim.newsham@guardent.com>
Niels Provos <provos@OpenBSD.org> for the revised algorithm
Affects: All released versions of FreeBSD 3.x, 4.x prior to 4.3.
FreeBSD 3.5-STABLE prior to the correction date.
FreeBSD 4.2-STABLE prior to the correction date.
Corrected: 2001-05-02 (FreeBSD 3.5-STABLE)
2001-04-18 (FreeBSD 4.3-RC)
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.
The algorithm used to generate TCP initial sequence numbers was
subject to statistical analysis, which allows an attacker to guess a
range of values likely to be in use by a given server at a moment in
time, based on observation of the value at a previous time (for
example, by initiating a TCP connection to an open port on the
server).
Note that this vulnerability is different to the vulnerability
described in Security Advisory 00:52 (which dealt with failure of the
PRNG used in the ISN generation algorithm; this advisory relates to a
higher-level weakness in the algorithm itself).
In order for this to be successfully exploited, the attacker must also
satisfy the following conditions:
a) be able to initiate a TCP connection to an open port on the server.
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 3.x and 4.x prior to the correction date
including 3.5.1-RELEASE and 4.2-RELEASE are vulnerable to this
problem. The problem was corrected prior to the release of FreeBSD
4.3-RELEASE by using the TCP ISN generation algorithm obtained from
OpenBSD, which uses a more sophisticated randomization method that is
believed not to be vulnerable to the problem described here.
A more satisfactory, long-term solution would be to implement the
algorithm described in RFC 1948; plans are underway to implement this
algorithm for FreeBSD, and it is likely that it will be included in
future releases of FreeBSD.
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
Possible workarounds for the vulnerability include one or more 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. As of
FreeBSD 4.2-RELEASE these services were not enabled by default.
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 (ingress
filtering) 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.3-RELEASE or
3.5.1-STABLE after the respective correction dates.
2) To patch your present system: download the relevant patch from the
below location, and execute the following commands as root:
[FreeBSD 4.1/4.2 base system]
This patch has been verified to apply to FreeBSD 4.1 and 4.2 only. It
may or may not apply to older releases. Users of FreeBSD 4.1 must
apply the patch from advisory 00:52 before applying this patch.
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:39/tcp-isn-4.2.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:39/tcp-isn-4.2.patch.asc
Verify the detached PGP signature using your PGP utility.
# cd /usr/src/sys/netinet
# patch -p < /path/to/patch
[ Recompile your kernel as described in
http://www.freebsd.org/handbook/kernelconfig.html and reboot the
system ]
[FreeBSD 3.5.1 base system]
The following patch applies to FreeBSD 3.5.1-RELEASE which has already
had the patch from advisory 00:52 applied.
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:39/tcp-isn-3.5.1-stable.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:39/tcp-isn-3.5.1-stable.patch.asc
The following patch applies to unpatched FreeBSD 3.5.1-RELEASE only.
It may or may not apply to older, unsupported releases.
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:39/tcp-isn-3.5.1-rel.patch
# fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-01:39/tcp-isn-3.5.1-rel.patch.asc
Verify the detached PGP signature using your PGP utility.
# cd /usr/src/sys/netinet
# patch -p < /path/to/patch
[ Recompile your kernel as described in
http://www.freebsd.org/handbook/kernelconfig.html and reboot the
system ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.5 (FreeBSD)
Comment: For info see http://www.gnupg.org
iQCVAwUBOvB10FUuHi5z0oilAQETgAP/T7SbJS12PBczn9SRWPQ5exuZYMoj1VxR
BJmeTafE1x3kBP195JkW3dF4klWynIgVakNtIndIH+pJvfBPe7Mo8PclKqRjEE2S
JLGtPFPq7bYp0/tyaFy6wm26cLPye4/3x6qLthC04/WZVI4rqg6nY1qoiKAUBu7Z
VFtFxTH+E/A=
=CkM7
-----END PGP SIGNATURE-----
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105022120.f42LK1386574>