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)
236 lines
10 KiB
Text
236 lines
10 KiB
Text
-----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-----
|