From owner-freebsd-announce Wed May 2 14:20:15 2001 Delivered-To: freebsd-announce@freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id E715A37B423; Wed, 2 May 2001 14:20:01 -0700 (PDT) (envelope-from security-advisories@FreeBSD.org) Received: (from kris@localhost) by freefall.freebsd.org (8.11.1/8.11.1) id f42LK1u86581; Wed, 2 May 2001 14:20:01 -0700 (PDT) (envelope-from security-advisories@FreeBSD.org) Date: Wed, 2 May 2001 14:20:01 -0700 (PDT) Message-Id: <200105022120.f42LK1u86581@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: kris set sender to security-advisories@FreeBSD.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-01:39.tcp-isn Reply-To: security-advisories@FreeBSD.org Sender: owner-freebsd-announce@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----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 Niels Provos 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----- This is the moderated mailing list freebsd-announce. The list contains announcements of new FreeBSD capabilities, important events and project milestones. See also the FreeBSD Web pages at http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-announce" in the body of the message From owner-freebsd-announce Wed May 2 20:58:28 2001 Delivered-To: freebsd-announce@freebsd.org Received: from winston.osd.bsdi.com (adsl-64-173-15-98.dsl.sntc01.pacbell.net [64.173.15.98]) by hub.freebsd.org (Postfix) with ESMTP id 8C0F637B422 for ; Wed, 2 May 2001 20:58:19 -0700 (PDT) (envelope-from jkh@osd.bsdi.com) Received: from localhost (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.3/8.11.2) with ESMTP id f433w9343203 for ; Wed, 2 May 2001 20:58:09 -0700 (PDT) (envelope-from jkh@osd.bsdi.com) To: announce@freebsd.org Subject: ANNOUNCE: Status update on ftp.freebsd.org AKA ftp.freesoftware.com X-Mailer: Mew version 1.94.1 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010502205809P.jkh@osd.bsdi.com> Date: Wed, 02 May 2001 20:58:09 -0700 From: Jordan Hubbard X-Dispatcher: imput version 20000228(IM140) Lines: 92 Sender: owner-freebsd-announce@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi folks, This is just a short note to discuss the current state of affairs with our master FTP site, explain what we're doing about it and combat some of the FUD floating around which has everyone from space aliens to Wind River Systems (who supply the space aliens with navigational software, of course) intentionally killing the site off. On April 20th, 2001, the day that FreeBSD 4.3 was due to be released, we lost access to our main FTP site, ftp.freesoftware.com, without any advance warning. Further investigation revealed that the problem was due to an unforeseen network outage which caused the hosting ISP to have to block access to the site. With one of their major links down, it was overloading the ISPs backup links and denying bandwidth to their other customers. It was also not clear to us, then or now, just how long the outage would last and whether this was to be a short-term or a long-term problem. With the release date for 4.3 already well publicized in advance and many people asking me for it, I decided to use one of our backup sites, the usw[1-6].freebsd.org cluster, and at least get the current releases bits up somewhere on an interim basis. Unfortunately, I really underestimated both the extent of the demand and the degree to which our big, fat Gigabit pipe at ftp.freesoftware.com has made distributing the bits to our mirrors look comparatively easy. Even with the login limits set *significantly* greater in favor of the registered mirror sites, and with multiple machines pulling the load, it quickly overwhelmed the new hosting infrastructure and resulted in significant bandwidth limiting on FTP traffic being instituted by the ISP. Even delaying the official announcement by 24 hours had no measurable effect on the overload since word of mouth and anticipation had already built demand beyond the saturation point. In short, what many of us have suspected for years turned out to be proven rather abruptly true: The FreeBSD.org services infrastructure has become overly reliant on resources which constitute single points of failure and lacks both sufficient tiering and redundancy in the face of such failure. We lost a key FTP resource and our entire distribution service essentially collapsed. The same may be true for CVSup, mail and WWW services and that's something we definitely need to look at. For now, the most critical item is to finish implementing the discussed-but-not-implemented ftp-master site scheme. A machine to serve as the project's "master FTP host" has been procured will shortly be available for FTP access. ONLY mirror sites will be allowed to connect to it, and it will always be pre-loaded with release bits, CERT advisories and anything else which requires the mirrors to have a head-start in advance of any public announcement. Announcements will only be made after a hand-inspection of the mirror sites reveals that a significant degree of propagation has taken place from the master site and not beforehand. What people currently regard as "ftp.freebsd.org" will become another tier of sites, probably served in round-robin DNS fashion, which have all agreed to meet the minimum requirements for being "full and complete mirrors" of the bits offered from ftp-master.freebsd.org. Existing mirror sites which wish to maintain only a subset of the master bits will become clients of these second-tier sites and subject to whatever distribution policies they institute. It would be my expectation that certain 2nd-tier sites will also have mirror access lists which favor the 3rd-tier sites over end-users, but that's a detail to be worked out over time. It's also not clear what, if anything, needs to be done to make sites like www.freebsd.org and hub.freebsd.org more reliable in the face of failure, but people can certainly expect that a good deal of thought will be going into answering those questions over the next few weeks. It certainly would have been nice to have had all of this been fixed before the release of 4.3, of course, and it's somewhat ironic that discussions about these very problems were occurring right around the same time, but it sometimes requires a truly painful experience to actually force an organization (or an individual for that matter) to both recognize and act on its shortcomings. The failure of the FTP site, the timing of FreeBSD 4.3 RELEASE and Wind River's acquisition of BSDi's BSD assets were simply unfortunate coincidences which had no causal link and I'd also be happy if people would stop inferring as much. Wind River has, in fact, indicated some interest in keeping the ftp.freesoftware.com site alive and we simply need to figure out the best way of doing so. As one might expect, a Gigabit connection and collocation facilities for a full 19" rack's worth of equipment doesn't come cheap! I will be releasing more information as the situation develops, both here and to the hubs@freebsd.org mailing list. Thanks, - Jordan This is the moderated mailing list freebsd-announce. The list contains announcements of new FreeBSD capabilities, important events and project milestones. See also the FreeBSD Web pages at http://www.freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-announce" in the body of the message