From owner-freebsd-announce Mon Oct 2 18:43:39 2000 Delivered-To: freebsd-announce@freebsd.org Received: from vnode.vmunix.com (vnode.vmunix.com [209.112.4.20]) by hub.freebsd.org (Postfix) with ESMTP id B04FA37B502 for ; Mon, 2 Oct 2000 18:43:35 -0700 (PDT) Received: by vnode.vmunix.com (Postfix, from userid 1005) id B1E5DE; Mon, 2 Oct 2000 21:43:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by vnode.vmunix.com (Postfix) with ESMTP id ABE2449A13 for ; Mon, 2 Oct 2000 21:43:29 -0400 (EDT) Date: Mon, 2 Oct 2000 21:43:29 -0400 (EDT) From: Chris Coleman To: announce@freebsd.org Subject: FreeBSD Real Quick Newsletter Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-announce@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all, I am changing the format and frequency of the Real Quick Newsletter. Instead of doing 4 specialized newsletters once a month, I am going to do a unified BSD newsletter once a week. This has some good and bad points. On the positive side, I can include more current data. However, it is no longer appropriate for FreeBSD-Announce. So, I have given it a new home. I have also archived all the old newsletters. You will need to SUBSCRIBE to the newsletter. http://www.daemonnews.org/mailman/listinfo/rqn You can view the archives here: http://www.daemonnews.org/newsletter Chris Coleman Daemon News http://www.daemonnews.org Bringing BSD together 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 Oct 4 14: 0: 2 2000 Delivered-To: freebsd-announce@freebsd.org Received: from envy.geekhouse.net (ether.osd.bsdi.com [204.216.28.196]) by hub.freebsd.org (Postfix) with ESMTP id 04F9137B502 for ; Wed, 4 Oct 2000 13:59:56 -0700 (PDT) Received: (from jim@localhost) by envy.geekhouse.net (8.11.0/8.11.0) id e94Kxu908112 for announce@FreeBSD.org; Wed, 4 Oct 2000 13:59:56 -0700 (PDT) (envelope-from jim) Date: Wed, 4 Oct 2000 13:59:56 -0700 From: Jim Mock To: announce@FreeBSD.org Subject: Final BSDCon Update Message-ID: <20001004135956.A7977@envy.geekhouse.net> Reply-To: jim@osd.bsdi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.9i Sender: owner-freebsd-announce@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As most of you know, BSDCon 2000 is right around the corner. The tutorial sessions begin on October 14th (10 days from now). With this in mind, the tutorials and hotel are starting to fill up. Kirk McKusick's BSD Internals tutorial has approximately 4 open slots, so those of you interested in attending it need to register ASAP. You can do so online at http://bsdcon.com/registration.php3, or by calling us at 1-925-691-2800. The conference will be held at the Hyatt Regency in Monterey, California (http://www.hyatt.com/usa/monterey/hotels/hotel_mrydm.html). A floor plan of the hotel is also available on the conference web site at http://bsdcon.com/floorplan1.php3. The Hyatt still does have some rooms available, but we recommend you move quickly in order to reserve yours because they're going fast. If the Hyatt fills up, a list of other hotels in the area is available at http://bsdcon.com/lodging.php3. Please keep in mind, however, that BSDCon is not the only conference occuring in Monterey during this time, so other hotels may fill up quickly as well. Pricing is as follows: Conference (Oct. 18-20): $495 Tutorial 1 (Oct. 14-15): $495 Tutorial 2 (Oct. 16-17): $495 Room rates at the Hyatt: $129/night In order to get the room rate, simply mention that you're attending BSDCon (or if they sound confused, BSD or BSDi). Information about Monterey and the surrounding area can also be found on the web site at http://bsdcon.com/lodging.php3. If you are interested in being a sponsor or exhibitor at BSDCon 2000, please visit our web site and read the information available there. Papers and Tutorials ==================== For more information on the tutorials being presented, please visit http://bsdcon.com/tutorials.php3 for a brief overview and outline of each. For a list of papers being presented, along with who is presenting them, please see http://bsdcon.com/schedule.php3. Please keep in mind that the rooms and speakers may change. If you have any questions about the conference, please contact us at info@bsdcon.com. Alternatively, you can contact us by phone at 1-925-691-2800 or fax at 1-925-674-0821. Thanks, - jim -- jim mock work: jim@osd.bsdi.com | jim@FreeBSD.org http://soupnazi.org/ BSDi Open Source Div | http://bsdi.com 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 Fri Oct 6 14:46: 3 2000 Delivered-To: freebsd-announce@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id D836D37B502; Fri, 6 Oct 2000 14:45:41 -0700 (PDT) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory: FreeBSD-SA-00:52.tcp-iss Reply-To: security-advisories@freebsd.org Message-Id: <20001006214541.D836D37B502@hub.freebsd.org> Date: Fri, 6 Oct 2000 14:45:41 -0700 (PDT) Sender: owner-freebsd-announce@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----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 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----- 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