From owner-freebsd-security@FreeBSD.ORG Sun Apr 18 04:57:30 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A252116A4CE for ; Sun, 18 Apr 2004 04:57:30 -0700 (PDT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2AF043D1F for ; Sun, 18 Apr 2004 04:57:29 -0700 (PDT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 39E89531F; Sun, 18 Apr 2004 13:57:22 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id AF250530D; Sun, 18 Apr 2004 13:55:44 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 3341733C6C; Sun, 18 Apr 2004 13:55:43 +0200 (CEST) To: Roger Marquis References: <20040417190059.06B0316A4F7@hub.freebsd.org> <20040418031017.98ACEDAC11@mx7.roble.com> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Sun, 18 Apr 2004 13:55:43 +0200 In-Reply-To: <20040418031017.98ACEDAC11@mx7.roble.com> (Roger Marquis's message of "Sat, 17 Apr 2004 20:10:17 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: freebsd-security@freebsd.org Subject: Re: Is log_in_vain really good or really bad? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2004 11:57:30 -0000 Roger Marquis writes: > This is hardware problem. Any ATA/SATA disk will suck up CPU with > every disk access. The solution is to switch to SCSI. This is simply not true, and hasn't been for about ten years. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Sun Apr 18 19:12:13 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F183E16A4CE for ; Sun, 18 Apr 2004 19:12:13 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0A8243D4C for ; Sun, 18 Apr 2004 19:12:13 -0700 (PDT) (envelope-from cristjc@comcast.net) Received: from blossom.cjclark.org (c-24-6-187-112.client.comcast.net[24.6.187.112]) by comcast.net (rwcrmhc11) with ESMTP id <2004041902121301300fddnde>; Mon, 19 Apr 2004 02:12:13 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.9p2/8.12.8) with ESMTP id i3J2Ce8B067337; Sun, 18 Apr 2004 19:12:40 -0700 (PDT) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.9p2/8.12.9/Submit) id i3J2CdQi067336; Sun, 18 Apr 2004 19:12:39 -0700 (PDT) (envelope-from cristjc@comcast.net) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Sun, 18 Apr 2004 19:12:39 -0700 From: "Crist J. Clark" To: z3l3zt@hackunite.net Message-ID: <20040419021239.GA67288@blossom.cjclark.org> References: <1998.213.112.193.35.1082212115.squirrel@mail.hackunite.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1998.213.112.193.35.1082212115.squirrel@mail.hackunite.net> User-Agent: Mutt/1.4.2.1i X-URL: http://people.freebsd.org/~cjc/ cc: freebsd-security@freebsd.org Subject: Re: Is log_in_vain really good or really bad? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Crist J. Clark" List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 02:12:14 -0000 On Sat, Apr 17, 2004 at 04:28:35PM +0200, z3l3zt@hackunite.net wrote: [snip] > My server box is a Intel Celeron 733Mhz, 384Mb of RAM.. yet it's slow from > time to time since I only run ATA66 due to the old motherboard. When this > "attack" occured yesterday, the box almost died and the box were working > 100%.. all users who were logged in got "spammed" since the default > *.emerg in /etc/syslog.conf is set to "*" .. Not sure what that has to do with anything. The log_in_vain messages get logged at "info" level. What messages were your users seeing? -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-security@FreeBSD.ORG Sun Apr 18 22:55:01 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D840516A4CE; Sun, 18 Apr 2004 22:55:01 -0700 (PDT) Received: from mxfep02.bredband.com (mxfep02.bredband.com [195.54.107.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9399343D5A; Sun, 18 Apr 2004 22:55:00 -0700 (PDT) (envelope-from z3l3zt@hackunite.net) Received: from mail.hackunite.net ([213.112.193.7] [213.112.193.7]) by mxfep02.bredband.com with SMTP <20040419055457.VRPU28534.mxfep02.bredband.com@mail.hackunite.net>; Mon, 19 Apr 2004 07:54:57 +0200 Received: from 213.112.193.91 (SquirrelMail authenticated user z3l3zt@hackunite.net) by mail.hackunite.net with HTTP; Mon, 19 Apr 2004 07:54:57 +0200 (CEST) Message-ID: <2220.213.112.193.91.1082354097.squirrel@mail.hackunite.net> In-Reply-To: <20040419021239.GA67288@blossom.cjclark.org> References: <1998.213.112.193.35.1082212115.squirrel@mail.hackunite.net> <20040419021239.GA67288@blossom.cjclark.org> Date: Mon, 19 Apr 2004 07:54:57 +0200 (CEST) From: "Jesper Wallin" To: "Crist J. Clark" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal cc: freebsd-security@freebsd.org Subject: Re: Is log_in_vain really good or really bad? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: z3l3zt@hackunite.net List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 05:55:02 -0000 > On Sat, Apr 17, 2004 at 04:28:35PM +0200, z3l3zt@hackunite.net wrote: > [snip] > >> My server box is a Intel Celeron 733Mhz, 384Mb of RAM.. yet it's slow from >> time to time since I only run ATA66 due to the old motherboard. When this >> "attack" occured yesterday, the box almost died and the box were working >> 100%.. all users who were logged in got "spammed" since the default >> *.emerg in /etc/syslog.conf is set to "*" .. > > Not sure what that has to do with anything. The log_in_vain messages get > logged at "info" level. What messages were your users seeing? > -- > Crist J. Clark | cjclark@alum.mit.edu > | cjclark@jhu.edu > http://people.freebsd.org/~cjc/ | cjc@freebsd.org > Heya.. The logs I got were "normal" log_in_vain logs.. the reason I detected this (or, I were asleep and my girlfriend detected it) was because the syslogd daemon did send messages to everyone logged in. Sure, you can DoS most things if you really want to, but a simple "connection flood" which is on even lower bandwidths shouldn't make the box die.. and no, SCSI might be faster, but if I can download/upload to the machine in 9000kb/s, then it should be fast enough to store the logs even if it's ATA66.. I also detected that if I nmap my own ip with log_in_vain enabled, I get the same errors.. the box doesn't die really but syslogd will start to spit it's output to all the users. Apr 16 19:38:07 omikron kernel: Connection attempt to UDP 213.112.193.67:32672 from 213.151.136.3:54568 Apr 16 19:38:07 omikron kernel: Connection attempt to UDP 213.112.193.67:39323 from 213.151.136.3:54568 Apr 16 19:38:07 omikron kernel: Connection attempt to UDP 213.112.193.67:33426 from 213.151.136.3:54568 Apr 16 19:38:07 omikron kernel: Connection attempt to UDP 213.112.193.67:32432 from 213.151.136.3:54568 Apr 16 19:38:07 omikron kernel: Connection attempt to UDP 213.112.193.67:39834 from 213.151.136.3:54568 Apr 16 19:38:07 omikron kernel: Connection attempt to UDP 213.112.193.67:37231 from 213.151.136.3:54568 Apr 16 19:38:07 omikron kernel: Connection attempt to UDP 213.112.193.67:33524 from 213.151.136.3:54568 Regards, Jesper Wallin From owner-freebsd-security@FreeBSD.ORG Fri Apr 16 15:50:42 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CCEB16A4CE for ; Fri, 16 Apr 2004 15:50:42 -0700 (PDT) Received: from isber.ucsb.edu (research.isber.ucsb.edu [128.111.147.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D61B43D5C for ; Fri, 16 Apr 2004 15:50:42 -0700 (PDT) (envelope-from randall@ucsb.edu) Received: from ip68-6-116-39.sb.sd.cox.net ([68.6.116.39] helo=home) by isber.ucsb.edu with asmtp (TLSv1:RC4-MD5:128) (Exim 3.36 #2) id 1BEcAL-000Csz-00; Fri, 16 Apr 2004 15:50:33 -0700 Message-ID: <02cf01c42405$39a33450$4102a8c0@home> From: "randall ehren" To: "Jason Stone" , References: <20040408144322.GA83448@bewilderbeast.blackhelicopters.org><20040413181943.GA55219@bewilderbeast.blackhelicopters.org><6.0.3.0.0.20040414230754.07d7cf18@209.112.4.2><6.0.3.0.0.20040415105459.0477f488@209.112.4.2><20040415180518.GA46433@phobos.osem.com> <20040416153835.K45935@walter> Date: Fri, 16 Apr 2004 15:50:32 -0700 Organization: ISBER MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Scanner: exiscan *1BEcAL-000Csz-00*LgtJ/sr2h6I* (ISBER - Institute for Social, Behavioral, and Economic Research) X-Mailman-Approved-At: Mon, 19 Apr 2004 02:31:39 -0700 Subject: Re: recommended SSL-friendly crypto accelerator X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2004 22:50:42 -0000 | > For $79, it's cheap enough that I could put a whole stack of them in a | > machine. Can FreeBSD take advantage of multiple cards like that? | | another question is, is there logic, either in the driver or in openssl, | to notice if crypto operations are getting backed up waiting for the | crypto card while the main cpu is idle and, in that case, to start doing | the crypto on the main cpu rather than on the crypto card? | | in other words, if the main cpu is actually way faster than the crypto | card, is it possible that the crypto card could actually _slow_ crypto | operations on that system? | | last time I checked, the stats on the cheap soekris cards were way slower | than the output of "openssl speed" run on my system during normal load.... how would one test this out: just run % openssl speed on a system with the card, and then again without the card? where are you referencing your stats from? -randall From owner-freebsd-security@FreeBSD.ORG Sat Apr 17 04:13:50 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E5BE16A4CE for ; Sat, 17 Apr 2004 04:13:50 -0700 (PDT) Received: from mxfep02.bredband.com (mxfep02.bredband.com [195.54.107.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4C2A43D31 for ; Sat, 17 Apr 2004 04:13:49 -0700 (PDT) (envelope-from z3l3zt@hackunite.net) Received: from mail.hackunite.net ([213.112.193.67] [213.112.193.67]) by mxfep02.bredband.com with SMTP <20040417111347.HPJB28534.mxfep02.bredband.com@mail.hackunite.net> for ; Sat, 17 Apr 2004 13:13:47 +0200 Received: from 213.112.193.35 (SquirrelMail authenticated user z3l3zt@hackunite.net) by mail.hackunite.net with HTTP; Sat, 17 Apr 2004 13:15:00 +0200 (CEST) Message-ID: <1881.213.112.193.35.1082200500.squirrel@mail.hackunite.net> Date: Sat, 17 Apr 2004 13:15:00 +0200 (CEST) From: "Jesper Wallin" To: freebsd-security@freebsd.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Mailman-Approved-At: Mon, 19 Apr 2004 02:31:39 -0700 Subject: Is log_in_vain really good or really bad? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Apr 2004 11:13:50 -0000 Heya.. Yesterday someone "attacked" by box by connection to several ports.. In other words, a simple portscan.. yet, since my box has "log_in_vain" enabled, so it tries to log everything to /var/log/messages, since the logfile got full and the size went over 100K, it tried to rotate the log to save diskspace. (Apr 16 21:00:00 omikron newsyslog[32137]: logfile turned over due to size>100K) My server box is a Intel Celeron 733Mhz, 384Mb of RAM.. yet it's slow from time to time since I only run ATA66 due to the old motherboard. When this "attack" occured yesterday, the box almost died and the box were working 100%.. all users who were logged in got "spammed" since the default *.emerg in /etc/syslog.conf is set to "*" .. Isn't this a quite simple way of making a DoS attack against a system? My box is running on 10mbit and the person who scanned my server were connecting from a cable connection.. Someone (even with lower bandwidth) can simply portscan a box with "log_in_vain" enabled and the box will go crazy trying to log/store it? Also, I'm not sure if it was a "general" portscan since the "blackhole" mostly slow down those quite much.. but since this had about 30-40 connections per second, it was a quite aggressive scan. I would be glad if anyone could tell me how to solve this and/or how to make sure it doesn't happen again. Regards, Jesper 'Z3l3zT' Wallin From owner-freebsd-security@FreeBSD.ORG Sun Apr 18 19:15:45 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6F5D16A4CF; Sun, 18 Apr 2004 19:15:45 -0700 (PDT) Received: from bimmer.dtmpower.net (bimmer.dtmpower.net [66.250.68.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91DED43D55; Sun, 18 Apr 2004 19:15:45 -0700 (PDT) (envelope-from jd@ods.org) Received: from localhost (localhost [127.0.0.1]) by bimmer.dtmpower.net (Postfix) with ESMTP id 5CFC66E85A; Sun, 18 Apr 2004 22:09:26 -0400 (EDT) Received: from bimmer.dtmpower.net ([127.0.0.1]) by localhost (bimmer.dtmpower.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77289-02; Sun, 18 Apr 2004 22:09:26 -0400 (EDT) Received: from pcp08928390pcs.anapol01.md.comcast.net (pcp08928390pcs.anapol01.md.comcast.net [68.50.232.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bimmer.dtmpower.net (Postfix) with ESMTP id 016D9536F5; Sun, 18 Apr 2004 22:09:26 -0400 (EDT) Date: Sun, 18 Apr 2004 22:15:43 -0400 From: Jason DiCioccio To: "Crist J. Clark" Message-ID: <2147483647.1082326543@pcp08928390pcs.anapol01.md.comcast.net> In-Reply-To: <20040419021239.GA67288@blossom.cjclark.org> References: <1998.213.112.193.35.1082212115.squirrel@mail.hackunite.net> <20040419021239.GA67288@blossom.cjclark.org> X-Mailer: Mulberry/3.1.2 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at dtmpower.net X-Mailman-Approved-At: Mon, 19 Apr 2004 02:31:39 -0700 cc: freebsd-security@freebsd.org Subject: Re: Is log_in_vain really good or really bad? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 02:15:46 -0000 I've actually seen something similar happen. What happens, is when syslog gets backed up with lots and lots and lots of messages, it leaks a couple via wall. I'm not sure why, but I've seen it happen. Usually you only receive a fragment of a log entry. Perhaps it's a bug in syslogd, but it's only occurred maybe 2-3 times with me, so I just wrote it off. Regards, -JD- --On Sunday, April 18, 2004 7:12 PM -0700 "Crist J. Clark" wrote: > On Sat, Apr 17, 2004 at 04:28:35PM +0200, z3l3zt@hackunite.net wrote: > [snip] > >> My server box is a Intel Celeron 733Mhz, 384Mb of RAM.. yet it's slow >> from time to time since I only run ATA66 due to the old motherboard. >> When this "attack" occurred yesterday, the box almost died and the box >> were working 100%.. all users who were logged in got "spammed" since the >> default *.emerg in /etc/syslog.conf is set to "*" .. > > Not sure what that has to do with anything. The log_in_vain messages get > logged at "info" level. What messages were your users seeing? > -- > Crist J. Clark | cjclark@alum.mit.edu > | cjclark@jhu.edu > http://people.freebsd.org/~cjc/ | cjc@freebsd.org > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to > "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-security@FreeBSD.ORG Mon Apr 19 02:59:34 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8355216A4CE for ; Mon, 19 Apr 2004 02:59:34 -0700 (PDT) Received: from mxfep02.bredband.com (mxfep02.bredband.com [195.54.107.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id A82AB43D39 for ; Mon, 19 Apr 2004 02:59:33 -0700 (PDT) (envelope-from z3l3zt@hackunite.net) Received: from mail.hackunite.net ([213.112.193.7] [213.112.193.7]) by mxfep02.bredband.com with SMTP <20040419095932.BAMK9494.mxfep02.bredband.com@mail.hackunite.net>; Mon, 19 Apr 2004 11:59:32 +0200 Received: from 213.112.193.91 (SquirrelMail authenticated user z3l3zt@hackunite.net) by mail.hackunite.net with HTTP; Mon, 19 Apr 2004 11:59:34 +0200 (CEST) Message-ID: <2711.213.112.193.91.1082368774.squirrel@mail.hackunite.net> In-Reply-To: <4083A0C2.3F86159E@kuzbass.ru> References: <1998.213.112.193.35.1082212115.squirrel@mail.hackunite.net> <20040419021239.GA67288@blossom.cjclark.org> <4083A0C2.3F86159E@kuzbass.ru> Date: Mon, 19 Apr 2004 11:59:34 +0200 (CEST) From: "Jesper Wallin" To: "Eugene Grosbein" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal cc: freebsd-security@freebsd.org Subject: Re: Is log_in_vain really good or really bad? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: z3l3zt@hackunite.net List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 09:59:34 -0000 > "Crist J. Clark" wrote: >> >> On Sat, Apr 17, 2004 at 04:28:35PM +0200, z3l3zt@hackunite.net wrote: >> [snip] >> >> > My server box is a Intel Celeron 733Mhz, 384Mb of RAM.. yet it's slow from >> > time to time since I only run ATA66 due to the old motherboard. When this >> > "attack" occured yesterday, the box almost died and the box were working >> > 100%.. all users who were logged in got "spammed" since the default >> > *.emerg in /etc/syslog.conf is set to "*" .. >> >> Not sure what that has to do with anything. The log_in_vain messages get >> logged at "info" level. What messages were your users seeing? >> -- >> Crist J. Clark | cjclark@alum.mit.edu > > I believe that was a bug in syslogd and this bug is already fixed > in both of CURRENT and STABLE for not so long. > > Eugene > Fixed you say.. I run FreeBSD 5.2.1-RELEASE-p5, yet it's there.. Regards, Jesper Wallin From owner-freebsd-security@FreeBSD.ORG Mon Apr 19 05:42:53 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57DD016A4CF for ; Mon, 19 Apr 2004 05:42:53 -0700 (PDT) Received: from smtp1.euronet.nl (smtp1.euronet.nl [194.134.35.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDCAA43D31 for ; Mon, 19 Apr 2004 05:42:52 -0700 (PDT) (envelope-from dodell@sitetronics.com) Received: from sitetronics.com (zp-c-13e65.mxs.adsl.euronet.nl [81.69.92.101]) by smtp1.euronet.nl (Postfix) with ESMTP id EA04D67218; Mon, 19 Apr 2004 14:42:50 +0200 (MEST) Message-ID: <4083C949.4060507@sitetronics.com> Date: Mon, 19 Apr 2004 14:42:49 +0200 From: "Devon H. O'Dell" User-Agent: Mozilla Thunderbird 0.5 (X11/20040319) X-Accept-Language: en-us, en MIME-Version: 1.0 To: z3l3zt@hackunite.net References: <1998.213.112.193.35.1082212115.squirrel@mail.hackunite.net> <20040419021239.GA67288@blossom.cjclark.org> <4083A0C2.3F86159E@kuzbass.ru> <2711.213.112.193.91.1082368774.squirrel@mail.hackunite.net> In-Reply-To: <2711.213.112.193.91.1082368774.squirrel@mail.hackunite.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-security@freebsd.org cc: Eugene Grosbein Subject: Re: Is log_in_vain really good or really bad? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 12:42:53 -0000 >>I believe that was a bug in syslogd and this bug is already fixed >>in both of CURRENT and STABLE for not so long. >> >>Eugene >> > > > Fixed you say.. I run FreeBSD 5.2.1-RELEASE-p5, yet it's there.. > > > Regards, > Jesper Wallin if (strncmp("RELEASE", "CURRENT", 6) != 0) fprintf(jesper, "``in both of CURRENT and STABLE for not so long.''); Please, before you give sarcastic remarks back to others who are trying to help, do a little logical thinking for yourself. Devon From owner-freebsd-security@FreeBSD.ORG Mon Apr 19 05:49:23 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8653C16A4CE for ; Mon, 19 Apr 2004 05:49:23 -0700 (PDT) Received: from smtp3.euronet.nl (smtp3.euronet.nl [194.134.35.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D80643D41 for ; Mon, 19 Apr 2004 05:49:23 -0700 (PDT) (envelope-from dodell@sitetronics.com) Received: from sitetronics.com (zp-c-13e65.mxs.adsl.euronet.nl [81.69.92.101]) by smtp3.euronet.nl (Postfix) with ESMTP id 23B8F39FD3; Mon, 19 Apr 2004 14:49:22 +0200 (MEST) Message-ID: <4083CAD0.7040509@sitetronics.com> Date: Mon, 19 Apr 2004 14:49:20 +0200 From: "Devon H. O'Dell" User-Agent: Mozilla Thunderbird 0.5 (X11/20040319) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Devon H. O'Dell" References: <1998.213.112.193.35.1082212115.squirrel@mail.hackunite.net> <20040419021239.GA67288@blossom.cjclark.org> <4083A0C2.3F86159E@kuzbass.ru> <2711.213.112.193.91.1082368774.squirrel@mail.hackunite.net> <4083C949.4060507@sitetronics.com> In-Reply-To: <4083C949.4060507@sitetronics.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Eugene Grosbein cc: freebsd-security@freebsd.org Subject: Re: Is log_in_vain really good or really bad? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 12:49:23 -0000 Devon H. O'Dell wrote: > if (strncmp("RELEASE", "CURRENT", 6) != 0) Serves me right ;) --Devon From owner-freebsd-security@FreeBSD.ORG Mon Apr 19 06:46:23 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D12D016A4CE for ; Mon, 19 Apr 2004 06:46:23 -0700 (PDT) Received: from mxfep01.bredband.com (mxfep01.bredband.com [195.54.107.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id E133043D1D for ; Mon, 19 Apr 2004 06:46:22 -0700 (PDT) (envelope-from z3l3zt@hackunite.net) Received: from mail.hackunite.net ([213.112.193.7] [213.112.193.7]) by mxfep01.bredband.com with SMTP id <20040419134621.IFQ29949.mxfep01.bredband.com@mail.hackunite.net> for ; Mon, 19 Apr 2004 15:46:21 +0200 Received: from 213.112.193.118 (SquirrelMail authenticated user z3l3zt@hackunite.net) by mail.hackunite.net with HTTP; Mon, 19 Apr 2004 15:46:25 +0200 (CEST) Message-ID: <1039.213.112.193.118.1082382385.squirrel@mail.hackunite.net> Date: Mon, 19 Apr 2004 15:46:25 +0200 (CEST) From: "Jesper Wallin" To: freebsd-security@freebsd.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Subject: Re: Is log_in_vain really good or really bad? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: z3l3zt@hackunite.net List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 13:46:23 -0000 > >>>I believe that was a bug in syslogd and this bug is already fixed in both of CURRENT and STABLE for not so long. >>> >>>Eugene >>> >> >> >> Fixed you say.. I run FreeBSD 5.2.1-RELEASE-p5, yet it's there.. >> >> >> Regards, >> Jesper Wallin > > if (strncmp("RELEASE", "CURRENT", 6) != 0) > fprintf(jesper, "``in both of CURRENT and STABLE for not so long.''); > > Please, before you give sarcastic remarks back to others who are trying to help, do a little logical thinking for yourself. > > Devon > Hello again.. Heh, it wasn't ment to be sarcastic, mean or anything else like that.. I just pointed out it's still in FreeBSD 5.2.1 RELEASE-p5.. if someone feels bad for this, sorry. Regards, Jesper Wallin From owner-freebsd-security@FreeBSD.ORG Mon Apr 19 12:04:04 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D19216A4CE for ; Mon, 19 Apr 2004 12:04:04 -0700 (PDT) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 354E443D54 for ; Mon, 19 Apr 2004 12:04:04 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))verified)) by gw.celabo.org (Postfix) with ESMTP id D2AD25482B for ; Mon, 19 Apr 2004 14:04:03 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 82E006D455; Mon, 19 Apr 2004 14:04:03 -0500 (CDT) Date: Mon, 19 Apr 2004 14:04:03 -0500 From: "Jacques A. Vidrine" To: freebsd-security@freebsd.org Message-ID: <20040419190403.GA17526@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , freebsd-security@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i Subject: VuXML and FreeBSD X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 19:04:04 -0000 Hello All, I'd like to bring to your attention the Vulnerabilities and eXposures Markup Language (VuXML) and associated resources. VuXML is a markup language designed for the documentation of security issues within a single package collection. Since about February of this year, we have been diligently documenting vulnerabilities in FreeBSD and the FreeBSD Ports Collection using VuXML. The Project's VuXML document is maintained in the FreeBSD repository, path ports/security/vuxml/vuln.xml. Any FreeBSD committer may make updates to this file. The FreeBSD security officer acts as editor. The contents of the FreeBSD Project VuXML document is made available in a human-friendly format at . There one may browse issues by date, package name, CVE name, and so forth. In addition, an RSS feed is available at , allowing one to keep informed using an RSS reader such as Straw. Some tools that use VuXML are available in the FreeBSD Ports Collection. `vxquery' (ports/security/vxquery) is a simple command line tool that parses the VuXML document directly. `portaudit' (ports/security/portaudit) uses a `distilled' version of the FreeBSD VuXML document to report which of your installed ports may be affected by security issues, as well as providing additional warnings when attempting to install ports. A mailing list has been established for the discussion of VuXML, . This is a forum for discussing: - VuXML itself, including the DTD and its evolution - entries in the FreeBSD VuXML document, including new submissions, corrections, and style issues - VuXML usage and tools - the VuXML web site (www.vuxml.org and vuxml.freebsd.org) To subscribe to the mailing list, visit or send a subscription request to . Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org As a postscript, I'm also happy to say that the OpenBSD Ports & Packages collection has adopted VuXML for documenting issues as well. See the announcement at ; the human-friendly contents at ; or the RSS feed at . The OpenBSD VuXML document is currently maintained in Robert Nagy's private repository. From owner-freebsd-security@FreeBSD.ORG Mon Apr 19 17:51:51 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C2EB16A4CE for ; Mon, 19 Apr 2004 17:51:51 -0700 (PDT) Received: from mx7.roble.com (mx7.roble.com [206.40.34.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 69C5643D41 for ; Mon, 19 Apr 2004 17:51:51 -0700 (PDT) (envelope-from marquis@roble.com) Received: by mx7.roble.com (Postfix, from userid 65534) id 04650DAFD5; Mon, 19 Apr 2004 17:51:50 -0700 (PDT) Date: Mon, 19 Apr 2004 17:51:49 -0700 (PDT) From: Roger Marquis To: freebsd-security@freebsd.org In-Reply-To: <20040420003036.GL18311@cowbert.net> References: <20040417190059.06B0316A4F7@hub.freebsd.org> <20040420003036.GL18311@cowbert.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-Id: <20040420005149.AF50FDAFCC@mx7.roble.com> X-Spam-Level: X-Spam-Status: No, hits=-4.9 required=6.0 tests=BAYES_00 autolearn=no version=2.63 Subject: Re: Is log_in_vain really good or really bad? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 00:51:51 -0000 Peter C. Lai wrote: > > This is hardware problem. Any ATA/SATA disk will suck up CPU with > > every disk access. > > Only if you are running your drive in PIO mode. The system starts up using the > highest UDMA level possible and I bet (hope) he checked the sysctl to make sure > it was at UDMA66. PIO mode, UDMA, 66/100, serial, all are factors but none compensate for the differences beteween SCSI and ATA in real world conditions. By real world I mean where there are multiple, simultaneous disks reads and writes. Too many "benchmarks" only test serial, non-multitasking disk access. In this mode ATA can be just as fast as SCSI and use nearly as little CPU. As soon as you factor in multitasking, however, it's a whole 'nother ballgame. I've seen 10K 160M SCSI drives handle 10x more data than the fastest UDMA100. With 15K drives and 320M becoming generally available SATA isn't even rated for 50% of SCSI's maximum throughput and that's before factoring in multitasking. In every test I've done with various disks and controllers SCSI has out-performed ATA by a wide margin in server performance. -- Roger Marquis Roble Systems Consulting http://www.roble.com/ From owner-freebsd-security@FreeBSD.ORG Mon Apr 19 02:50:05 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6F3416A4CE; Mon, 19 Apr 2004 02:50:05 -0700 (PDT) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 077E843D49; Mon, 19 Apr 2004 02:50:02 -0700 (PDT) (envelope-from eugen@kuzbass.ru) Received: from kuzbass.ru (kost [213.184.65.82])i3J9nwM4068962; Mon, 19 Apr 2004 17:49:58 +0800 (KRAST) (envelope-from eugen@kuzbass.ru) Message-ID: <4083A0C2.3F86159E@kuzbass.ru> Date: Mon, 19 Apr 2004 17:49:54 +0800 From: Eugene Grosbein Organization: SVZServ X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: ru,en MIME-Version: 1.0 To: "Crist J. Clark" References: <1998.213.112.193.35.1082212115.squirrel@mail.hackunite.net> <20040419021239.GA67288@blossom.cjclark.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 20 Apr 2004 02:16:30 -0700 cc: freebsd-security@freebsd.org Subject: Re: Is log_in_vain really good or really bad? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2004 09:50:05 -0000 "Crist J. Clark" wrote: > > On Sat, Apr 17, 2004 at 04:28:35PM +0200, z3l3zt@hackunite.net wrote: > [snip] > > > My server box is a Intel Celeron 733Mhz, 384Mb of RAM.. yet it's slow from > > time to time since I only run ATA66 due to the old motherboard. When this > > "attack" occured yesterday, the box almost died and the box were working > > 100%.. all users who were logged in got "spammed" since the default > > *.emerg in /etc/syslog.conf is set to "*" .. > > Not sure what that has to do with anything. The log_in_vain messages get > logged at "info" level. What messages were your users seeing? > -- > Crist J. Clark | cjclark@alum.mit.edu I believe that was a bug in syslogd and this bug is already fixed in both of CURRENT and STABLE for not so long. Eugene From owner-freebsd-security@FreeBSD.ORG Mon Apr 19 18:56:39 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 582B316A4CF for ; Mon, 19 Apr 2004 18:56:39 -0700 (PDT) Received: from staff.seccuris.com (staff.seccuris.com [204.112.0.40]) by mx1.FreeBSD.org (Postfix) with SMTP id C22AB43D45 for ; Mon, 19 Apr 2004 18:56:38 -0700 (PDT) (envelope-from maneo@bsdpro.com) Received: (qmail 85734 invoked by uid 1006); 20 Apr 2004 01:56:38 -0000 Date: Tue, 20 Apr 2004 01:56:38 +0000 From: "Christian S.J. Peron" To: freebsd-hackers@FreeBSD.org Message-ID: <20040420015638.A84821@staff.seccuris.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Mailman-Approved-At: Tue, 20 Apr 2004 02:16:30 -0700 cc: freebsd-security@FreeBSD.org Subject: [patch] Raw sockets in jails X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 01:56:39 -0000 Although RAW sockets can be used when specifying the source address of packets (defeating one of the aspects of the jail) some people may find it usefull to use utilities like ping(8) or traceroute(8) from inside jails. Enclosed is a patch I have written which gives you the option of allowing prison-root to create raw sockets inside the prison, so that programs various network debugging programs like ping and traceroute etc can be used. This patch will create the security.jail.allow_raw_sockets sysctl MIB. I would appriciate any feed-back from testers See PR #: http://www.freebsd.org/cgi/query-pr.cgi?pr=65800 -------------------- SNIP SNIP ------------------------ --- sys/kern/kern_jail.c.bak Mon Apr 19 16:55:40 2004 +++ sys/kern/kern_jail.c Mon Apr 19 17:56:03 2004 @@ -53,6 +53,11 @@ &jail_sysvipc_allowed, 0, "Processes in jail can use System V IPC primitives"); +int jail_allow_raw_sockets = 0; +SYSCTL_INT(_security_jail, OID_AUTO, allow_raw_sockets, CTLFLAG_RW, + &jail_allow_raw_sockets, 0, + "Prison root can create raw sockets"); + /* allprison, lastprid, and prisoncount are protected by allprison_mtx. */ struct prisonlist allprison; struct mtx allprison_mtx; --- sys/netinet/raw_ip.c.b Mon Apr 19 16:23:57 2004 +++ sys/netinet/raw_ip.c Mon Apr 19 17:55:08 2004 @@ -40,6 +40,7 @@ #include "opt_random_ip_id.h" #include +#include #include #include #include @@ -505,6 +506,7 @@ } } +extern int jail_allow_raw_sockets; u_long rip_sendspace = RIPSNDQ; u_long rip_recvspace = RIPRCVQ; @@ -527,7 +529,11 @@ INP_INFO_WUNLOCK(&ripcbinfo); return EINVAL; } - if (td && (error = suser(td)) != 0) { + if (td && jailed(td->td_ucred) && !jail_allow_raw_sockets) { + INP_INFO_WUNLOCK(&ripcbinfo); + return (EPERM); + } + if (td && (error = suser_cred(td->td_ucred, PRISON_ROOT)) != 0) { INP_INFO_WUNLOCK(&ripcbinfo); return error; } From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 02:20:48 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D42C416A4D0; Tue, 20 Apr 2004 02:20:48 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EE3343D2D; Tue, 20 Apr 2004 02:20:48 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i3K9KbE5014523; Tue, 20 Apr 2004 11:20:43 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: "Christian S.J. Peron" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 20 Apr 2004 01:56:38 -0000." <20040420015638.A84821@staff.seccuris.com> Date: Tue, 20 Apr 2004 11:20:37 +0200 Message-ID: <14522.1082452837@critter.freebsd.dk> cc: freebsd-hackers@freebsd.org cc: freebsd-security@freebsd.org Subject: Re: [patch] Raw sockets in jails X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 09:20:49 -0000 In message <20040420015638.A84821@staff.seccuris.com>, "Christian S.J. Peron" w rites: > > Although RAW sockets can be used when specifying the source > address of packets (defeating one of the aspects of the jail) > some people may find it usefull to use utilities like ping(8) > or traceroute(8) from inside jails. > > Enclosed is a patch I have written which gives you the option > of allowing prison-root to create raw sockets inside the prison, > so that programs various network debugging programs like ping > and traceroute etc can be used. > > This patch will create the security.jail.allow_raw_sockets sysctl > MIB. I would appriciate any feed-back from testers > > See PR #: > http://www.freebsd.org/cgi/query-pr.cgi?pr=65800 Could you take a peek and see how hard it would be to enforce source-IP compliance with the jail restriction ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 09:56:30 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 436B116A4CE for ; Tue, 20 Apr 2004 09:56:30 -0700 (PDT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF85443D1F for ; Tue, 20 Apr 2004 09:56:29 -0700 (PDT) (envelope-from mike@sentex.net) Received: from avscan2.sentex.ca (avscan2.sentex.ca [199.212.134.19]) by smtp3b.sentex.ca (8.12.11/8.12.11) with ESMTP id i3KGuSlJ078750 for ; Tue, 20 Apr 2004 12:56:28 -0400 (EDT) (envelope-from mike@sentex.net) Received: from localhost (localhost [127.0.0.1]) by avscan2.sentex.ca (Postfix) with ESMTP id 5A88759C89 for ; Tue, 20 Apr 2004 12:56:28 -0400 (EDT) Received: from avscan2.sentex.ca ([127.0.0.1]) by localhost (avscan2.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 73108-01 for ; Tue, 20 Apr 2004 12:56:28 -0400 (EDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan2.sentex.ca (Postfix) with ESMTP id 4106E59C93 for ; Tue, 20 Apr 2004 12:56:28 -0400 (EDT) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id i3KGuMkL039240 for ; Tue, 20 Apr 2004 12:56:27 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> X-Sender: mdtpop@209.112.4.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Tue, 20 Apr 2004 12:57:25 -0400 To: freebsd-security@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at (avscan2) sentex.ca Subject: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 16:56:30 -0000 http://www.uniras.gov.uk/vuls/2004/236929/index.htm ----Quote---- "The impact of this vulnerability varies by vendor and application, but in some deployment scenarios it is rated critical. Please see the vendor section below for further information. Alternatively contact your vendor for product specific information. If exploited, the vulnerability could allow an attacker to create a Denial of Service condition against existing TCP connections, resulting in premature session termination. The resulting session termination will affect the application layer, the nature and severity of the effects being dependent on the application layer protocol. The primary dependency is on the duration of the TCP connection, with a further dependency on knowledge of the network (IP) addresses of the end points of the TCP connection." ----Quote---- -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 10:44:58 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3E0316A4CE for ; Tue, 20 Apr 2004 10:44:58 -0700 (PDT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89A9743D3F for ; Tue, 20 Apr 2004 10:44:58 -0700 (PDT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 9E3DA531B; Tue, 20 Apr 2004 19:44:57 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 32F0B530D; Tue, 20 Apr 2004 19:44:38 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id D4A7833C6C; Tue, 20 Apr 2004 19:44:37 +0200 (CEST) To: Mike Tancsa References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Tue, 20 Apr 2004 19:44:37 +0200 In-Reply-To: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> (Mike Tancsa's message of "Tue, 20 Apr 2004 12:57:25 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: freebsd-security@freebsd.org Subject: Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 17:44:58 -0000 Mike Tancsa writes: > http://www.uniras.gov.uk/vuls/2004/236929/index.htm The advisory grossly exaggerates the impact and severity of this fea^H^H^Hbug. The attack is only practical if you already know the details of the TCP connection you are trying to attack, or are in a position to sniff it. The fact that you can attack a TCP connection which passes through a network you have access to sniff should not be a surprise to anyone; the remaining cases require spoofing of a type which egress filtering would prevent, if only people would bother implementing it. I don't believe BGP sessions are as exposed as the advisory claims they are, either. The possibility of insertion attacks (which are quite hard) was predicted six years ago, when RFC 2385 (Protection of BGP Sessions via the TCP MD5 Signature Option) was written. RST attacks may cause route flapping, but that can be avoided with a short hysteresis (though this may be impractical for backbone routers) Insertion attacks against SSL connections are practically impossible, so the only risk there is an RST attack, which most browsers should handle gracefully. DNS connections (even zone transfers) are so short-lived that you would have to be very, very lucky to pull off an insertion or RST attack against. The most likely attack scenario to come out of this is probably gamers and IRC weenies kicking eachother off servers (the server's IP address and port number are known, the servers often reveal client IP addresses to other clients, and the client often uses a fixed source port, or one from a relatively small range) DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 11:17:21 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64CE816A4CE for ; Tue, 20 Apr 2004 11:17:21 -0700 (PDT) Received: from post.kyx.net (mail.kyx.net [216.232.31.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1543143D3F for ; Tue, 20 Apr 2004 11:17:21 -0700 (PDT) (envelope-from dr@kyx.net) Received: from zylinator.zorg (unknown [216.232.31.80]) by post.kyx.net (Postfix) with ESMTP id C1A11D0A2C; Tue, 20 Apr 2004 11:28:15 -0700 (PDT) From: Dragos Ruiu Organization: All Terrain Ninjas To: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=), Mike Tancsa Date: Tue, 20 Apr 2004 11:13:27 -0700 User-Agent: KYX-CP/M-FNORD5602 References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200404201113.27737.dr@kyx.net> cc: freebsd-security@freebsd.org Subject: Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 18:17:21 -0000 On April 20, 2004 10:44 am, Dag-Erling Sm=F8rgrav wrote: > Mike Tancsa writes: > > http://www.uniras.gov.uk/vuls/2004/236929/index.htm > > The advisory grossly exaggerates the impact and severity of this > fea^H^H^Hbug. The attack is only practical if you already know the > details of the TCP connection you are trying to attack, or are in a > position to sniff it. The fact that you can attack a TCP connection > which passes through a network you have access to sniff should not be > a surprise to anyone; the remaining cases require spoofing of a type > which egress filtering would prevent, if only people would bother > implementing it. > This is not true. The attack does not require sniffing. > I don't believe BGP sessions are as exposed as the advisory claims > they are, either. The possibility of insertion attacks (which are > quite hard) was predicted six years ago, when RFC 2385 (Protection of > BGP Sessions via the TCP MD5 Signature Option) was written. RST > attacks may cause route flapping, but that can be avoided with a short > hysteresis (though this may be impractical for backbone routers) > While I might agree that the real world practicability of the attack needs to be carefully estimated, as there are a couple of complicating factors (window size, and frequency of updates which fight against each other). This does require much further analysis. I've been working with several people to try to get better analysis and correlation/verification of Paul's data... and the results are inconclusive. This MIGHT not be as big a problem as it seems, but the lab data that Paul has indicates it's something to seriously look at anyway. Cisco PSIRT will be doing a Q&A on the topic after Paul's presentation and we'll have some very sharp technical guys in the audience, including some folks from very large ISPs that are most likely to be affected, so I will wait untill I hear from people smarter than I analyzing this. The discussion should prove interesting and informative I hope. =20 cheers, =2D-dr =2D-=20 Top security experts. Cutting edge tools, techniques and information. Vancouver, Canada April 21-23 2004 http://cansecwest.com pgpkey http://dragos.com/ kyxpgp From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 11:26:31 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85ED216A4CE for ; Tue, 20 Apr 2004 11:26:31 -0700 (PDT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2AC143D49 for ; Tue, 20 Apr 2004 11:26:30 -0700 (PDT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id BE1CB5311; Tue, 20 Apr 2004 20:26:29 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id ABF55530A; Tue, 20 Apr 2004 20:26:17 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 580C033C6C; Tue, 20 Apr 2004 20:26:17 +0200 (CEST) To: Dragos Ruiu References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <200404201113.27737.dr@kyx.net> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Tue, 20 Apr 2004 20:26:17 +0200 In-Reply-To: <200404201113.27737.dr@kyx.net> (Dragos Ruiu's message of "Tue, 20 Apr 2004 11:13:27 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: freebsd-security@freebsd.org Subject: Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 18:26:31 -0000 Dragos Ruiu writes: > On April 20, 2004 10:44 am, Dag-Erling Sm=F8rgrav wrote: > > The advisory grossly exaggerates the impact and severity of this > > fea^H^H^Hbug. The attack is only practical if you already know the > > details of the TCP connection you are trying to attack, or are in a > > position to sniff it. > This is not true. The attack does not require sniffing. You need to know the source and destination IP and port. In most cases, this means sniffing. BGP is easier because the destination port is always 179 and the source and destination IPs are recorded in the whois database, but you still need to know the source port. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 11:41:46 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1349216A4CE for ; Tue, 20 Apr 2004 11:41:46 -0700 (PDT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C269F43D1F for ; Tue, 20 Apr 2004 11:41:45 -0700 (PDT) (envelope-from mike@sentex.net) Received: from avscan1.sentex.ca (avscan1.sentex.ca [199.212.134.11]) by smtp3b.sentex.ca (8.12.11/8.12.11) with ESMTP id i3KIfhEq003758; Tue, 20 Apr 2004 14:41:43 -0400 (EDT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan1.sentex.ca (8.12.10/8.12.10) with ESMTP id i3KIfh3x018297; Tue, 20 Apr 2004 14:41:43 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id i3KIfg48039704; Tue, 20 Apr 2004 14:41:42 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> X-Sender: mdtpop@209.112.4.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Tue, 20 Apr 2004 14:43:25 -0400 To: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= ) From: Mike Tancsa In-Reply-To: References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <200404201113.27737.dr@kyx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new cc: freebsd-security@freebsd.org Subject: Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 18:41:46 -0000 At 02:26 PM 20/04/2004, Dag-Erling Sm=F8rgrav wrote: >Dragos Ruiu writes: > > On April 20, 2004 10:44 am, Dag-Erling Sm=F8rgrav wrote: > > > The advisory grossly exaggerates the impact and severity of this > > > fea^H^H^Hbug. The attack is only practical if you already know the > > > details of the TCP connection you are trying to attack, or are in a > > > position to sniff it. > > This is not true. The attack does not require sniffing. > >You need to know the source and destination IP and port. In most >cases, this means sniffing. BGP is easier because the destination >port is always 179 and the source and destination IPs are recorded in >the whois database, but you still need to know the source port. While true, you do need the source port, how long will it take to=20 programmatically go through the possible source ports in an attack ? That=20 only adds 2^16-1024 to blast through ---Mike >DES >-- >Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 13:23:47 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 150F416A4CE for ; Tue, 20 Apr 2004 13:23:47 -0700 (PDT) Received: from avalon.linuxpowered.com (avalon.linuxpowered.com [64.246.60.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id D39D743D1D for ; Tue, 20 Apr 2004 13:23:46 -0700 (PDT) (envelope-from diz@linuxpowered.com) Received: from linuxpowered.com (txirvcom-itnfw01.verizon.com [::ffff:192.76.54.20]) (AUTH: CRAM-MD5 diz@linuxpowered.com) by avalon.linuxpowered.com with esmtp; Tue, 20 Apr 2004 15:32:43 -0500 Message-ID: <408586B2.8020900@linuxpowered.com> Date: Tue, 20 Apr 2004 15:23:14 -0500 From: masta Organization: wifibsd.org User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Tancsa References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <200404201113.27737.dr@kyx.net> <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> In-Reply-To: <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= cc: freebsd-security@freebsd.org Subject: Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: masta@wifibsd.org List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 20:23:47 -0000 Does anybody remember this: http://lcamtuf.coredump.cx/newtcp/ This seems fairly clear to me that guessing our tcp sequences is near omnipotent power. -Jon Mike Tancsa wrote: > At 02:26 PM 20/04/2004, Dag-Erling Smørgrav wrote: > >> Dragos Ruiu writes: >> > On April 20, 2004 10:44 am, Dag-Erling Smørgrav wrote: >> > > The advisory grossly exaggerates the impact and severity of this >> > > fea^H^H^Hbug. The attack is only practical if you already know the >> > > details of the TCP connection you are trying to attack, or are in a >> > > position to sniff it. >> > This is not true. The attack does not require sniffing. >> >> You need to know the source and destination IP and port. In most >> cases, this means sniffing. BGP is easier because the destination >> port is always 179 and the source and destination IPs are recorded in >> the whois database, but you still need to know the source port. > > > While true, you do need the source port, how long will it take to > programmatically go through the possible source ports in an attack ? > That only adds 2^16-1024 to blast through > > ---Mike > > > > > >> DES >> -- >> Dag-Erling Smørgrav - des@des.no > > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to > "freebsd-security-unsubscribe@freebsd.org" > From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 13:24:28 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60F9916A4CF for ; Tue, 20 Apr 2004 13:24:28 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3748843D60 for ; Tue, 20 Apr 2004 13:24:28 -0700 (PDT) (envelope-from cristjc@comcast.net) Received: from blossom.cjclark.org (c-24-6-187-112.client.comcast.net[24.6.187.112]) by comcast.net (rwcrmhc12) with ESMTP id <2004042020242701400rlu17e>; Tue, 20 Apr 2004 20:24:27 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.9p2/8.12.8) with ESMTP id i3KKON8B004407 for ; Tue, 20 Apr 2004 13:24:27 -0700 (PDT) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.9p2/8.12.9/Submit) id i3KKOM7T004406 for freebsd-security@freebsd.org; Tue, 20 Apr 2004 13:24:23 -0700 (PDT) (envelope-from cristjc@comcast.net) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Tue, 20 Apr 2004 13:24:22 -0700 From: "Crist J. Clark" To: freebsd-security@freebsd.org Message-ID: <20040420202422.GB3727@blossom.cjclark.org> References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <200404201113.27737.dr@kyx.net> <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> User-Agent: Mutt/1.4.2.1i X-URL: http://people.freebsd.org/~cjc/ Subject: Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Crist J. Clark" List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 20:24:28 -0000 Arguments on the severity of the bug aside, FreeBSD does not have a working RFC2385 implementation. And despite any particular FreeBSD developer's opinion of the severity, there will be some FreeBSD consumers who want RFC2385. Anyone working on it or already have patches? -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 13:24:45 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7C6FB16A4DA; Tue, 20 Apr 2004 13:24:45 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AD7943D5D; Tue, 20 Apr 2004 13:24:44 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i3KKOcoc023454; Tue, 20 Apr 2004 22:24:39 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: "Christian S.J. Peron" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 20 Apr 2004 20:00:27 -0000." <20040420200027.A51891@staff.seccuris.com> Date: Tue, 20 Apr 2004 22:24:38 +0200 Message-ID: <23453.1082492678@critter.freebsd.dk> cc: freebsd-hackers@freebsd.org cc: freebsd-security@freebsd.org Subject: Re: [patch] Raw sockets in jails X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 20:24:45 -0000 In message <20040420200027.A51891@staff.seccuris.com>, "Christian S.J. Peron" w rites: >Poul/group > >The following patch makes raw sockets comply with prison IP addresses. >Some tools such as traceroute(8) may require that the prison IP address >be specified on the command line. I.E. > > traceroute -s > >Otherwise it might fail. How does traceroute and ping normally determine which source address to use ? Can't we use that mechanism to default them to the right thing ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 13:29:06 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0033616A4CE for ; Tue, 20 Apr 2004 13:29:05 -0700 (PDT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id C663343D1F for ; Tue, 20 Apr 2004 13:29:05 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i3KKT55l025203 for ; Tue, 20 Apr 2004 13:29:05 -0700 (PDT) Received: from [10.1.1.193] (nfw2.codefab.com [199.103.21.225] (may be forged)) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 3.0) with ESMTP id i3KKT4TK025848 for ; Tue, 20 Apr 2004 13:29:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <593EE0FE-9309-11D8-A8CA-003065ABFD92@mac.com> Content-Transfer-Encoding: quoted-printable From: Charles Swiger Date: Tue, 20 Apr 2004 16:28:56 -0400 To: freebsd-security@freebsd.org X-Mailer: Apple Mail (2.613) Subject: Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 20:29:06 -0000 On Apr 20, 2004, at 1:44 PM, Dag-Erling Sm=F8rgrav wrote: > Mike Tancsa writes: >> http://www.uniras.gov.uk/vuls/2004/236929/index.htm > > The advisory grossly exaggerates the impact and severity of this > fea^H^H^Hbug. The attack is only practical if you already know the > details of the TCP connection you are trying to attack, or are in a > position to sniff it. The fact that you can attack a TCP connection > which passes through a network you have access to sniff should not be > a surprise to anyone; the remaining cases require spoofing of a type > which egress filtering would prevent, if only people would bother > implementing it. My take on this is pretty close to yours: this isn't a new=20 vulnerability and it's difficult to perform this type of attack under=20 most circumstances without being able to sniff the traffic going by. =20 (Basicly, sending a RST is a simple form of data injection via the=20 classic man-in-the-middle attack. ACKs and RSTs count as data, too. =20 :-) Egress filtering is a fine idea, but I don't see that it would help=20 much in this case. Ingress filtering-- ie, traffic from IP block=20 x.x.x.x/yy must come via interface Z-- and blocking source-routing=20 would seem to be more helpful. It's not clear to me that this advisory is particularly relevant to=20 FreeBSD in the sense that there is some change that ought to be made at=20= the OS-level to mitigate against such attacks: using IPsec, SSL port=20 forwarding, and such are already well-supported under FreeBSD. Using a tiny window (say ethernet MTU or smaller) would greatly=20 increase the amount of work an attacker has to do to create a valid RST=20= to zap an open connection, admittedly at the cost of adding a lot of=20 latency to such TCP connections. Hmm, how about a mechanism that would=20= let one control the maximum TCP window size the system will permit on a=20= per-host or per-network-block basis? --=20 -Chuck From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 13:36:13 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04E3A16A4CE for ; Tue, 20 Apr 2004 13:36:13 -0700 (PDT) Received: from post.kyx.net (mail.kyx.net [216.232.31.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9179043D53 for ; Tue, 20 Apr 2004 13:36:12 -0700 (PDT) (envelope-from dr@kyx.net) Received: from zylinator.zorg (unknown [216.232.31.80]) by post.kyx.net (Postfix) with ESMTP id 3DEEFD0A2C; Tue, 20 Apr 2004 13:47:07 -0700 (PDT) From: Dragos Ruiu Organization: All Terrain Ninjas To: Mike Tancsa , des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= ) Date: Tue, 20 Apr 2004 13:32:40 -0700 User-Agent: KYX-CP/M-FNORD5602 References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> In-Reply-To: <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200404201332.40827.dr@kyx.net> cc: freebsd-security@freebsd.org Subject: Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 20:36:13 -0000 On April 20, 2004 11:43 am, Mike Tancsa wrote: > At 02:26 PM 20/04/2004, Dag-Erling Sm=F8rgrav wrote: > >Dragos Ruiu writes: > > > On April 20, 2004 10:44 am, Dag-Erling Sm=F8rgrav wrote: > > > > The advisory grossly exaggerates the impact and severity of this > > > > fea^H^H^Hbug. The attack is only practical if you already know the > > > > details of the TCP connection you are trying to attack, or are in a > > > > position to sniff it. > > > > > > This is not true. The attack does not require sniffing. > > > >You need to know the source and destination IP and port. In most > >cases, this means sniffing. BGP is easier because the destination > >port is always 179 and the source and destination IPs are recorded in > >the whois database, but you still need to know the source port. > > While true, you do need the source port, how long will it take to > programmatically go through the possible source ports in an attack ? That > only adds 2^16-1024 to blast through Also keep in mind ports are predictable to varying degrees depending on the vendor or OS, which further reduces the brute force space you have to=20 go though without sniffing. That's what this thing boils down to imho - the space you have to blast through, the time you have to do it in, and=20 the bandwidth/rate available to do it. And there are competing factors, and questions about what are the real world values. I'm still waiting on final answers... cheers, =2D-dr =2D-=20 Top security experts. Cutting edge tools, techniques and information. Vancouver, Canada April 21-23 2004 http://cansecwest.com pgpkey http://dragos.com/ kyxpgp From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 13:45:22 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3007D16A4DC for ; Tue, 20 Apr 2004 13:45:21 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC13A43D48 for ; Tue, 20 Apr 2004 13:45:21 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i3KKjL7Z090657; Tue, 20 Apr 2004 13:45:21 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i3KKjKSb090656; Tue, 20 Apr 2004 13:45:20 -0700 (PDT) (envelope-from dillon) Date: Tue, 20 Apr 2004 13:45:20 -0700 (PDT) From: Matthew Dillon Message-Id: <200404202045.i3KKjKSb090656@apollo.backplane.com> To: Charles Swiger References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <593EE0FE-9309-11D8-A8CA-003065ABFD92@mac.com> cc: freebsd-security@freebsd.org Subject: Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 20:45:22 -0000 Well, the advisory certainly exaggerates some, but I think there is a real issue with BGP and I have to respectfully disagree with DES. Route flapping cannot be solved by reducing hysteresis, at least not unless you want your backbone provider to cut you off! Flapping is a major problem... less of one now then when I was doing BEST a decade ago, but still very serious. When a BGP session flaps it has to resynchronize, and resynchronization can take a significant period of time, bandwidth, and router resources to accomplish. You can't just reconnect and pick up where you left off (if you could it would be a non-problem). On the other hand, BGP can be trivially protected. You don't need ingress or egress filtering at all (by which I mean IP block filtering), you simply disable the routing of any packet to or from port 179. 99.9% of all BGP links are direct connections (meaning that they terminate at a router rather then pass through one). No packet to or from port 179 has any business being routed from one network to another in virtually all BGP link setups so the fix is utterly trivial. -Matt From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 13:46:35 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E27416A4CE for ; Tue, 20 Apr 2004 13:46:35 -0700 (PDT) Received: from skyweb.ca (smtp-1.vancouver.ipapp.com [216.152.192.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A24043D46 for ; Tue, 20 Apr 2004 13:46:35 -0700 (PDT) (envelope-from mjohnston@skyweb.ca) Received: from [192.168.15.191] ([64.42.246.34]) by smtp-1.vancouver.ipapp.com ; Tue, 20 Apr 2004 13:46:34 -0700 From: Mark Johnston To: freebsd-security@freebsd.org Date: Tue, 20 Apr 2004 15:47:14 -0500 User-Agent: KMail/1.6.1 References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> <20040420202422.GB3727@blossom.cjclark.org> In-Reply-To: <20040420202422.GB3727@blossom.cjclark.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200404201547.14796.mjohnston@skyweb.ca> X-Rcpt-To: X-Country: CA Subject: Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 20:46:35 -0000 "Crist J. Clark" wrote: > Arguments on the severity of the bug aside, FreeBSD does not > have a working RFC2385 implementation. It looks like bms@ committed half of one in February: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1056731+0+/usr/local/www/db/text/2004/cvs-all/20040215.cvs-all The vulnerability would still exist when the spoofed packets are directed towards a FreeBSD router, but it looks like this would protect its RFC2385-capable partner from the attack. That doesn't help if the attacker knows which side of the link is which platform, but it reduces the likelihood of an unresearched attack being successful. Mark From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 13:47:17 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD30116A520 for ; Tue, 20 Apr 2004 13:47:17 -0700 (PDT) Received: from post.kyx.net (mail.kyx.net [216.232.31.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66A8943D49 for ; Tue, 20 Apr 2004 13:47:15 -0700 (PDT) (envelope-from dr@kyx.net) Received: from zylinator.zorg (unknown [216.232.31.80]) by post.kyx.net (Postfix) with ESMTP id 96CDDD0A2C; Tue, 20 Apr 2004 13:58:10 -0700 (PDT) From: Dragos Ruiu Organization: All Terrain Ninjas To: Charles Swiger , freebsd-security@freebsd.org Date: Tue, 20 Apr 2004 13:43:44 -0700 User-Agent: KYX-CP/M-FNORD5602 References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <593EE0FE-9309-11D8-A8CA-003065ABFD92@mac.com> In-Reply-To: <593EE0FE-9309-11D8-A8CA-003065ABFD92@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200404201343.44342.dr@kyx.net> Subject: Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 20:47:17 -0000 On April 20, 2004 01:28 pm, Charles Swiger wrote: > My take on this is pretty close to yours: this isn't a new > vulnerability and it's difficult to perform this type of attack under > most circumstances without being able to sniff the traffic going by. > (Basicly, sending a RST is a simple form of data injection via the > classic man-in-the-middle attack. ACKs and RSTs count as data, too. Definitely not a new vulnerability. Just a newer analysis with more factors accounted for. > Using a tiny window (say ethernet MTU or smaller) would greatly > increase the amount of work an attacker has to do to create a valid RST > to zap an open connection, admittedly at the cost of adding a lot of > latency to such TCP connections. Hmm, how about a mechanism that would > let one control the maximum TCP window size the system will permit on a > per-host or per-network-block basis? But I'm told most providers crank UP their window sizes to improve BGP restarts... So reducing the windows may negatively affect other things. (Need to be careful that the cure isn't worse than the disease.) cheers, --dr -- Top security experts. Cutting edge tools, techniques and information. Vancouver, Canada April 21-23 2004 http://cansecwest.com pgpkey http://dragos.com/ kyxpgp From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 14:16:35 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0363916A4CE for ; Tue, 20 Apr 2004 14:16:35 -0700 (PDT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id E41BB43D58 for ; Tue, 20 Apr 2004 14:16:34 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i3KLGV5l001545; Tue, 20 Apr 2004 14:16:34 -0700 (PDT) Received: from [10.1.1.193] (nfw2.codefab.com [199.103.21.225] (may be forged)) (authenticated bits=0)i3KLGUgQ028043; Tue, 20 Apr 2004 14:16:31 -0700 (PDT) In-Reply-To: <200404201343.44342.dr@kyx.net> References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <593EE0FE-9309-11D8-A8CA-003065ABFD92@mac.com> <200404201343.44342.dr@kyx.net> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Tue, 20 Apr 2004 17:16:25 -0400 To: Dragos Ruiu X-Mailer: Apple Mail (2.613) cc: freebsd-security@freebsd.org Subject: Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 21:16:35 -0000 On Apr 20, 2004, at 4:43 PM, Dragos Ruiu wrote: > On April 20, 2004 01:28 pm, Charles Swiger wrote: >> My take on this is pretty close to yours: this isn't a new >> vulnerability and it's difficult to perform this type of attack under >> most circumstances without being able to sniff the traffic going by. >> (Basicly, sending a RST is a simple form of data injection via the >> classic man-in-the-middle attack. ACKs and RSTs count as data, too. > > Definitely not a new vulnerability. Just a newer analysis with more > factors accounted for. Agreed. For those who don't get them, CERT just released an advisory (TA04-111A) about this issue which contains some more specific information: "According to Paul Watson's report, with a typical xDSL data connection (80 Kbps, upstream) capable of sending of 250 packets per second (pps) to a session with a TCP Window size of 65,535 bytes, it would be possible to inject a TCP packet approximately every 5 minutes. It would take approximately 15 seconds with a T-1 (1.544 Mbps) connection." [ ...thought about reducing TCP window size... ] > But I'm told most providers crank UP their window sizes to improve BGP > restarts... So reducing the windows may negatively affect other things. > (Need to be careful that the cure isn't worse than the disease.) Oh, sure. My suggestion was not specifically oriented towards BGP, since that already has mechanisms available to protect it (TCP MD5 checksums) and for the reasons that Matt Dillon mentioned-- it's easy to firewall off port 179, or have your BGP peers talking out-of-band via an appropriate network topology. -- -Chuck From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 14:20:48 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5699F16A4CE; Tue, 20 Apr 2004 14:20:48 -0700 (PDT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD6AE43D1F; Tue, 20 Apr 2004 14:20:47 -0700 (PDT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 6AF6E5311; Tue, 20 Apr 2004 23:20:46 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 84C6D530A; Tue, 20 Apr 2004 23:20:39 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 2B09633C6C; Tue, 20 Apr 2004 23:20:39 +0200 (CEST) To: "Crist J. Clark" References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <200404201113.27737.dr@kyx.net> <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> <20040420202422.GB3727@blossom.cjclark.org> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Tue, 20 Apr 2004 23:20:39 +0200 In-Reply-To: <20040420202422.GB3727@blossom.cjclark.org> (Crist J. Clark's message of "Tue, 20 Apr 2004 13:24:22 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: freebsd-security@freebsd.org Subject: Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 21:20:48 -0000 "Crist J. Clark" writes: > Arguments on the severity of the bug aside, FreeBSD does not > have a working RFC2385 implementation. And despite any particular > FreeBSD developer's opinion of the severity, there will be some > FreeBSD consumers who want RFC2385. Anyone working on it or=20 > already have patches? We already have a partial implementation in the tree, and work is ongoing to complete it. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 16:38:32 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04E7416A4CE; Tue, 20 Apr 2004 16:38:32 -0700 (PDT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE45243D3F; Tue, 20 Apr 2004 16:38:31 -0700 (PDT) (envelope-from mike@sentex.net) Received: from avscan2.sentex.ca (avscan2.sentex.ca [199.212.134.19]) by smtp3b.sentex.ca (8.12.11/8.12.11) with ESMTP id i3KNcVjY050032; Tue, 20 Apr 2004 19:38:31 -0400 (EDT) (envelope-from mike@sentex.net) Received: from localhost (localhost [127.0.0.1]) by avscan2.sentex.ca (Postfix) with ESMTP id 3061F59DD3; Tue, 20 Apr 2004 19:38:31 -0400 (EDT) Received: from avscan2.sentex.ca ([127.0.0.1]) by localhost (avscan2.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 47035-11; Tue, 20 Apr 2004 19:38:31 -0400 (EDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan2.sentex.ca (Postfix) with ESMTP id 17C9359D9A; Tue, 20 Apr 2004 19:38:31 -0400 (EDT) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id i3KNcTXK040908; Tue, 20 Apr 2004 19:38:30 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.0.3.0.0.20040420193554.07da5780@209.112.4.2> X-Sender: mdtpop@209.112.4.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Tue, 20 Apr 2004 19:40:23 -0400 To: "Crist J. Clark" , freebsd-security@freebsd.org From: Mike Tancsa In-Reply-To: <20040420202422.GB3727@blossom.cjclark.org> References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <200404201113.27737.dr@kyx.net> <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> <20040420202422.GB3727@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at (avscan2) sentex.ca Subject: Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 23:38:32 -0000 At 04:24 PM 20/04/2004, Crist J. Clark wrote: >Arguments on the severity of the bug aside, FreeBSD does not >have a working RFC2385 implementation. Most of it is there http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netipsec/ipsec.h has info about it. bms@freebsd.org is also working on completing the rest. I have been using his patches against quagga on a directly connected ebgp peer as well as an ebgp multi-hop peer as well for a good 2 months and it works as expected. ---Mike >And despite any particular >FreeBSD developer's opinion of the severity, there will be some >FreeBSD consumers who want RFC2385. Anyone working on it or >already have patches? >-- >Crist J. Clark | cjclark@alum.mit.edu > | cjclark@jhu.edu >http://people.freebsd.org/~cjc/ | cjc@freebsd.org >_______________________________________________ >freebsd-security@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-security >To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 16:38:45 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67B5916A4E4 for ; Tue, 20 Apr 2004 16:38:45 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08CE443D1F for ; Tue, 20 Apr 2004 16:38:45 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 318E165473; Wed, 21 Apr 2004 00:38:43 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16225-03-6; Wed, 21 Apr 2004 00:38:42 +0100 (BST) Received: from empiric.dek.spc.org (82-147-17-88.dsl.uk.rapidplay.com [82.147.17.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id B4A9C653AE; Wed, 21 Apr 2004 00:38:41 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 6075360EE; Wed, 21 Apr 2004 00:38:40 +0100 (BST) Date: Wed, 21 Apr 2004 00:38:40 +0100 From: Bruce M Simpson To: Mark Johnston Message-ID: <20040420233840.GJ724@empiric.dek.spc.org> Mail-Followup-To: Mark Johnston , freebsd-security@freebsd.org References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> <20040420202422.GB3727@blossom.cjclark.org> <200404201547.14796.mjohnston@skyweb.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404201547.14796.mjohnston@skyweb.ca> cc: freebsd-security@freebsd.org Subject: Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 23:38:45 -0000 On Tue, Apr 20, 2004 at 03:47:14PM -0500, Mark Johnston wrote: > "Crist J. Clark" wrote: > > Arguments on the severity of the bug aside, FreeBSD does not > > have a working RFC2385 implementation. > > It looks like bms@ committed half of one in February: And is busy working on the other half as we speak. BMS From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 17:03:00 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60A1B16A4CE for ; Tue, 20 Apr 2004 17:03:00 -0700 (PDT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28E9443D54 for ; Tue, 20 Apr 2004 17:03:00 -0700 (PDT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 3F4A06542C; Wed, 21 Apr 2004 01:02:59 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16620-01-2; Wed, 21 Apr 2004 01:02:58 +0100 (BST) Received: from empiric.dek.spc.org (82-147-17-88.dsl.uk.rapidplay.com [82.147.17.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 4A5C7653E8; Wed, 21 Apr 2004 01:02:58 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 80C3B60EE; Wed, 21 Apr 2004 01:02:54 +0100 (BST) Date: Wed, 21 Apr 2004 01:02:54 +0100 From: Bruce M Simpson To: Matthew Dillon Message-ID: <20040421000254.GK724@empiric.dek.spc.org> Mail-Followup-To: Matthew Dillon , Charles Swiger , freebsd-security@freebsd.org References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <593EE0FE-9309-11D8-A8CA-003065ABFD92@mac.com> <200404202045.i3KKjKSb090656@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404202045.i3KKjKSb090656@apollo.backplane.com> cc: freebsd-security@freebsd.org Subject: Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 00:03:00 -0000 On Tue, Apr 20, 2004 at 01:45:20PM -0700, Matthew Dillon wrote: > 99.9% of all BGP links are direct connections (meaning that they > terminate at a router rather then pass through one). No packet to > or from port 179 has any business being routed from one network to > another in virtually all BGP link setups so the fix is utterly trivial. This isn't necessarily the case with eBGP multihop or route-server based setups. Regards, BMS From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 17:09:39 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 350C716A4CE for ; Tue, 20 Apr 2004 17:09:39 -0700 (PDT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D98C943D3F for ; Tue, 20 Apr 2004 17:09:38 -0700 (PDT) (envelope-from mike@sentex.net) Received: from avscan1.sentex.ca (avscan1.sentex.ca [199.212.134.11]) by smtp3b.sentex.ca (8.12.11/8.12.11) with ESMTP id i3L09ZXB052847; Tue, 20 Apr 2004 20:09:35 -0400 (EDT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan1.sentex.ca (8.12.10/8.12.10) with ESMTP id i3L09Z3x029090; Tue, 20 Apr 2004 20:09:35 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id i3L09YcI040979; Tue, 20 Apr 2004 20:09:34 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.0.3.0.0.20040420200911.08a87fa8@209.112.4.2> X-Sender: mdtpop@209.112.4.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Tue, 20 Apr 2004 20:11:31 -0400 To: Matthew Dillon From: Mike Tancsa In-Reply-To: <20040421000254.GK724@empiric.dek.spc.org> References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <593EE0FE-9309-11D8-A8CA-003065ABFD92@mac.com> <200404202045.i3KKjKSb090656@apollo.backplane.com> <20040421000254.GK724@empiric.dek.spc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new cc: freebsd-security@freebsd.org Subject: Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 00:09:39 -0000 At 08:02 PM 20/04/2004, Bruce M Simpson wrote: >On Tue, Apr 20, 2004 at 01:45:20PM -0700, Matthew Dillon wrote: > > 99.9% of all BGP links are direct connections (meaning that they > > terminate at a router rather then pass through one). No packet to > > or from port 179 has any business being routed from one network to > > another in virtually all BGP link setups so the fix is utterly trivial. > >This isn't necessarily the case with eBGP multihop or route-server based >setups. Cogent and 360/GT both like to do ebgp multihop by default. ---Mike From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 18:05:19 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D021316A4CF for ; Tue, 20 Apr 2004 18:05:19 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94E7843D5E for ; Tue, 20 Apr 2004 18:05:19 -0700 (PDT) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id DB3E05C808; Tue, 20 Apr 2004 16:46:17 -0700 (PDT) Date: Tue, 20 Apr 2004 16:46:17 -0700 From: Bill Fumerola To: Matthew Dillon Message-ID: <20040420234617.GO17862@elvis.mu.org> References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <593EE0FE-9309-11D8-A8CA-003065ABFD92@mac.com> <200404202045.i3KKjKSb090656@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404202045.i3KKjKSb090656@apollo.backplane.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 4.10-MUORG-20040412 i386 X-PGP-Key: 1024D/7F868268 X-PGP-Fingerprint: 5B2D 908E 4C2B F253 DAEB FC01 8436 B70B 7F86 8268 cc: freebsd-security@freebsd.org Subject: Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 01:05:20 -0000 On Tue, Apr 20, 2004 at 01:45:20PM -0700, Matthew Dillon wrote: > On the other hand, BGP can be trivially protected. You don't need > ingress or egress filtering at all (by which I mean IP block filtering), > you simply disable the routing of any packet to or from port 179. > 99.9% of all BGP links are direct connections (meaning that they > terminate at a router rather then pass through one). No packet to > or from port 179 has any business being routed from one network to > another in virtually all BGP link setups so the fix is utterly trivial. most multi-router, multi-link setups use peering with a multihop address of some other router (or route server) to provide equal cost balancing. RFC3682 describes something along the same vein of what you suggest, but handles non-directly connected cases (multihop, tunnels, etc) better. vendor J lets you dynamically build your firewall rules such that you can actually just create a term "allow from all bgp neighbors in the config AND port 179 AND protocol tcp". vendor C would do well to provide something similar. those running freebsd bgp daemons should consider building something similar that feeds ${freebsd_packet_filter} from a ${freebsd_routing_daemon} configuration file. -- - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 18:59:04 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47CEE16A4CE for ; Tue, 20 Apr 2004 18:59:04 -0700 (PDT) Received: from caligula.anu.edu.au (caligula.anu.edu.au [150.203.224.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B30143D31 for ; Tue, 20 Apr 2004 18:59:03 -0700 (PDT) (envelope-from avalon@caligula.anu.edu.au) Received: from caligula.anu.edu.au (localhost [127.0.0.1]) by caligula.anu.edu.au (8.12.9/8.12.9) with ESMTP id i3L1wxbF010199 for ; Wed, 21 Apr 2004 11:58:59 +1000 (EST) Received: (from avalon@localhost) by caligula.anu.edu.au (8.12.9/8.12.8/Submit) id i3L1wxoM010197 for freebsd-security@freebsd.org; Wed, 21 Apr 2004 11:58:59 +1000 (EST) From: Darren Reed Message-Id: <200404210158.i3L1wxoM010197@caligula.anu.edu.au> To: freebsd-security@freebsd.org Date: Wed, 21 Apr 2004 11:58:59 +1000 (Australia/ACT) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 01:59:04 -0000 Forwarded message: > From full-disclosure-admin@lists.netsys.com Wed Apr 21 11:49:12 2004 > To: full-disclosure@lists.netsys.com > From: Darren Bounds > Subject: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability > Date: Tue, 20 Apr 2004 18:19:58 -0400 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt > > > > Darren Bounds, CISSP > > 443D 628D 0AC7 CACF 6085 > C0E0 B2FC 534B 3D9E 69AF > > - -- > Intrusense - Securing Business As Usual > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (Darwin) > > iD8DBQFAhaITsvxTSz2eaa8RAtQWAKCvKFFp0oS7VkjswUelIlOIhESoPgCeLqg4 > 2DmvTJTfsx8af50acb+OJ9g= > =zPCJ > -----END PGP SIGNATURE----- > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 20:12:14 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1957E16A4CE for ; Tue, 20 Apr 2004 20:12:14 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D85643D46 for ; Tue, 20 Apr 2004 20:12:13 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i3L3Bt7E045458; Tue, 20 Apr 2004 20:11:59 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200404210311.i3L3Bt7E045458@gw.catspoiler.org> Date: Tue, 20 Apr 2004 20:11:55 -0700 (PDT) From: Don Lewis To: avalon@caligula.anu.edu.au In-Reply-To: <200404210158.i3L1wxoM010197@caligula.anu.edu.au> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-security@FreeBSD.org Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 03:12:14 -0000 On 21 Apr, Darren Reed wrote: > Forwarded message: >> From full-disclosure-admin@lists.netsys.com Wed Apr 21 11:49:12 2004 >> To: full-disclosure@lists.netsys.com >> From: Darren Bounds >> Subject: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability >> Date: Tue, 20 Apr 2004 18:19:58 -0400 >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt I saw this draft earlier today. RFC793 [1] currently requires handling of a segment with the RST bit when in a synchronized state to be processed as follows: 1) If the RST bit is set and the sequence number is outside the expected window, silently drop the segment. 2) If the RST bit is set and the sequence number is acceptable i.e.: (RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND) then reset the connection. Instead, the following changes should be made to provide some protection against such an attack. A) If the RST bit is set and the sequence number is outside the expected window, silently drop the segment. B) If the RST bit is exactly the next expected sequence number, reset the connection. C) If the RST bit is set and the sequence number does not exactly match the next expected sequence value, yet is within the acceptable window (RCV.NXT < SEG.SEQ <= RCV.NXT+RCV.WND) send an acknowledgment. Our original implementation of the RST sequence number checking was much more permissive than RFC 793. I submitted a patch, which was included in tcp_input.c version 1.81 that implemented steps A and B above. It was discovered that this is incompatible with certain peers, so the code was changed to match RFC 793 in tcp_input.c 1.98. I don't know if adding step C will fix the problem. There may further info in the list archives. From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 20:47:09 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D67616A4CE for ; Tue, 20 Apr 2004 20:47:09 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2647143D5C for ; Tue, 20 Apr 2004 20:47:09 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i3L3ki7E045504; Tue, 20 Apr 2004 20:46:48 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200404210346.i3L3ki7E045504@gw.catspoiler.org> Date: Tue, 20 Apr 2004 20:46:44 -0700 (PDT) From: Don Lewis To: avalon@caligula.anu.edu.au In-Reply-To: <200404210311.i3L3Bt7E045458@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-security@FreeBSD.org Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 03:47:09 -0000 On 20 Apr, Don Lewis wrote: > On 21 Apr, Darren Reed wrote: >>> http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt > > I saw this draft earlier today. > > RFC793 [1] currently requires handling of a segment with the RST bit > when in a synchronized state to be processed as follows: > 1) If the RST bit is set and the sequence number is outside the > expected window, silently drop the segment. > 2) If the RST bit is set and the sequence number is acceptable i.e.: > (RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND) then reset the connection. > > > Instead, the following changes should be made to provide some > protection against such an attack. > A) If the RST bit is set and the sequence number is outside the > expected window, silently drop the segment. > B) If the RST bit is exactly the next expected sequence number, reset > the connection. > C) If the RST bit is set and the sequence number does not exactly > match the next expected sequence value, yet is within the > acceptable window (RCV.NXT < SEG.SEQ <= RCV.NXT+RCV.WND) send an > acknowledgment. > > > Our original implementation of the RST sequence number checking was much > more permissive than RFC 793. I submitted a patch, which was included > in tcp_input.c version 1.81 that implemented steps A and B above. It > was discovered that this is incompatible with certain peers, so the code > was changed to match RFC 793 in tcp_input.c 1.98. > > I don't know if adding step C will fix the problem. There may further > info in the list archives. >From what I see here: I am concerned that step C will not solve the compatibility problem. The FreeBSD host is sending a FIN to close an established connection, and the peer host adding the window size advertised in the FIN packet to the sequence number acknowledged in the FIN packet, and using the sum as the sequence number for the RST packet, which puts the sequence number at the end of the receive window. From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 23:44:51 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5896016A4CF for ; Tue, 20 Apr 2004 23:44:51 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id C2FFB43D5C for ; Tue, 20 Apr 2004 23:44:48 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 68753 invoked from network); 21 Apr 2004 06:44:47 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 21 Apr 2004 06:44:47 -0000 X-pair-Authenticated: 209.68.2.70 Date: Wed, 21 Apr 2004 01:50:28 -0500 (CDT) From: Mike Silbersack To: Don Lewis In-Reply-To: <200404210346.i3L3ki7E045504@gw.catspoiler.org> Message-ID: <20040421014736.H1228@odysseus.silby.com> References: <200404210346.i3L3ki7E045504@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-security@FreeBSD.org cc: avalon@caligula.anu.edu.au Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 06:44:51 -0000 On Tue, 20 Apr 2004, Don Lewis wrote: > I am concerned that step C will not solve the compatibility problem. The > FreeBSD host is sending a FIN to close an established connection, and > the peer host adding the window size advertised in the FIN packet to the > sequence number acknowledged in the FIN packet, and using the sum as the > sequence number for the RST packet, which puts the sequence number at > the end of the receive window. Would it be feasible for us to create a four to five element array to track "resettable" sequence numbers? This could hold the sequence numbers of the last few packets transmitted, and account for that edge case as well. I'm very uneasy with the IETF step C - sending more packets out into the network sounds like a new type of amplification attack. Mike "Silby" Silbersack From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 23:50:19 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BE4616A4CE; Tue, 20 Apr 2004 23:50:19 -0700 (PDT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D3A743D5D; Tue, 20 Apr 2004 23:50:18 -0700 (PDT) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.11/8.12.11) with ESMTP id i3L6o7BO026772; Wed, 21 Apr 2004 08:50:08 +0200 (CEST) (envelope-from phk@phk.freebsd.dk) To: Mike Silbersack From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 21 Apr 2004 01:50:28 CDT." <20040421014736.H1228@odysseus.silby.com> Date: Wed, 21 Apr 2004 08:50:07 +0200 Message-ID: <26771.1082530207@critter.freebsd.dk> cc: freebsd-security@freebsd.org cc: Don Lewis cc: avalon@caligula.anu.edu.au Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 06:50:19 -0000 In message <20040421014736.H1228@odysseus.silby.com>, Mike Silbersack writes: > >On Tue, 20 Apr 2004, Don Lewis wrote: > >> I am concerned that step C will not solve the compatibility problem. The >> FreeBSD host is sending a FIN to close an established connection, and >> the peer host adding the window size advertised in the FIN packet to the >> sequence number acknowledged in the FIN packet, and using the sum as the >> sequence number for the RST packet, which puts the sequence number at >> the end of the receive window. > >Would it be feasible for us to create a four to five element array to >track "resettable" sequence numbers? This could hold the sequence numbers >of the last few packets transmitted, and account for that edge case as >well. Sounds like an interesting idea. Technically you will have to hold the sequence numbers for all non-ACK'ed packets, which may be up to the window divided by the MTU. In the conventional case, worst case is 237 sequence numbers (65535/276). This sounds like a lot until one realizes that at the same time we hold 64k of un-ACK'ed data. A prototype would be a good thing... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 04:29:33 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91F8816A4CE for ; Wed, 21 Apr 2004 04:29:33 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C9B443D45 for ; Wed, 21 Apr 2004 04:29:33 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i3LBTH7E046516; Wed, 21 Apr 2004 04:29:21 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200404211129.i3LBTH7E046516@gw.catspoiler.org> Date: Wed, 21 Apr 2004 04:29:17 -0700 (PDT) From: Don Lewis To: silby@silby.com In-Reply-To: <20040421014736.H1228@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-security@FreeBSD.org cc: avalon@caligula.anu.edu.au Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 11:29:33 -0000 On 21 Apr, Mike Silbersack wrote: > > On Tue, 20 Apr 2004, Don Lewis wrote: > >> I am concerned that step C will not solve the compatibility problem. The >> FreeBSD host is sending a FIN to close an established connection, and >> the peer host adding the window size advertised in the FIN packet to the >> sequence number acknowledged in the FIN packet, and using the sum as the >> sequence number for the RST packet, which puts the sequence number at >> the end of the receive window. > > Would it be feasible for us to create a four to five element array to > track "resettable" sequence numbers? This could hold the sequence numbers > of the last few packets transmitted, and account for that edge case as > well. I'm very uneasy with the IETF step C - sending more packets out > into the network sounds like a new type of amplification attack. I'd be concerned about the extra memory, especially in cases where we want to support very large numbers of connections. As far as amplification, step C has a gain of less than one, since packets are only transmitted if the incoming packet hits the window, and they will be the same or smaller in size than the incoming packets. I don't know if it would be valid to rate limit them ... If this is the only edge case that we have to worry about, we might be able change the test to: if (th->th_seq == tp->last_ack_sent || th->th_seq == tp->last_ack_sent + tp->rcv_wnd - 1) { From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 04:51:35 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2271A16A4CE for ; Wed, 21 Apr 2004 04:51:35 -0700 (PDT) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id D63D443D31 for ; Wed, 21 Apr 2004 04:51:34 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from localhost (localhost [127.0.0.1]) by gw.celabo.org (Postfix) with ESMTP id 62C3E54899; Wed, 21 Apr 2004 06:51:34 -0500 (CDT) Received: from gw.celabo.org ([127.0.0.1]) by localhost (hellblazer.celabo.org [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 84127-03; Wed, 21 Apr 2004 06:51:23 -0500 (CDT) Received: from lum.celabo.org (lum.celabo.org [10.0.1.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "lum.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id BAC1454861; Wed, 21 Apr 2004 06:51:23 -0500 (CDT) Received: by lum.celabo.org (Postfix, from userid 501) id 399C21D0B2E; Wed, 21 Apr 2004 06:10:03 -0500 (CDT) Date: Wed, 21 Apr 2004 06:10:03 -0500 From: "Jacques A. Vidrine" To: Dragos Ruiu Message-ID: <20040421111003.GB19640@lum.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Dragos Ruiu , Mike Tancsa , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , freebsd-security@freebsd.org References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> <200404201332.40827.dr@kyx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404201332.40827.dr@kyx.net> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: freebsd-security@freebsd.org cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Subject: Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 11:51:35 -0000 On Tue, Apr 20, 2004 at 01:32:40PM -0700, Dragos Ruiu wrote: > Also keep in mind ports are predictable to varying degrees depending on > the vendor or OS, which further reduces the brute force space you have to > go though without sniffing. This is exactly why I ported OpenBSD's TCP ephemeral port allocation randomization to FreeBSD-CURRENT (although I asked Mike Silby to commit it for me and take the blame if it broke :-). It will also be MFC'd shortly in time for 4.10-RELEASE. Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 04:51:47 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A2AC16A4CE for ; Wed, 21 Apr 2004 04:51:47 -0700 (PDT) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC73B43D2D for ; Wed, 21 Apr 2004 04:51:46 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from localhost (localhost [127.0.0.1]) by gw.celabo.org (Postfix) with ESMTP id 7325B5489C; Wed, 21 Apr 2004 06:51:46 -0500 (CDT) Received: from gw.celabo.org ([127.0.0.1]) by localhost (hellblazer.celabo.org [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 84139-03; Wed, 21 Apr 2004 06:51:35 -0500 (CDT) Received: from lum.celabo.org (lum.celabo.org [10.0.1.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "lum.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id 922815486E; Wed, 21 Apr 2004 06:51:24 -0500 (CDT) Received: by lum.celabo.org (Postfix, from userid 501) id 7CDDE1D0CF9; Wed, 21 Apr 2004 06:47:20 -0500 (CDT) Date: Wed, 21 Apr 2004 06:47:20 -0500 From: "Jacques A. Vidrine" To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20040421114720.GD19738@lum.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , Mike Tancsa , freebsd-security@freebsd.org References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i Content-Transfer-Encoding: quoted-printable cc: freebsd-security@freebsd.org Subject: Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 11:51:47 -0000 On Tue, Apr 20, 2004 at 07:44:37PM +0200, Dag-Erling Sm=F8rgrav wrote: > Mike Tancsa writes: > > http://www.uniras.gov.uk/vuls/2004/236929/index.htm >=20 > The advisory grossly exaggerates the impact and severity of this > fea^H^H^Hbug. The attack is only practical if you already know the > details of the TCP connection you are trying to attack, or are in a > position to sniff it. =20 Well, the whole point is that *although in the past it was widely believed otherwise*, this attack is practical today in some real world situations. It many cases the only unknown is the source port number, and even that can be predictable. [...] > I don't believe BGP sessions are as exposed as the advisory claims > they are, either. The possibility of insertion attacks (which are > quite hard) was predicted six years ago, when RFC 2385 (Protection of > BGP Sessions via the TCP MD5 Signature Option) was written. RST > attacks may cause route flapping, but that can be avoided with a short > hysteresis (though this may be impractical for backbone routers) If the DoS attack causes route flapping, then the attack is a success. > Insertion attacks against SSL connections are practically impossible, > so the only risk there is an RST attack, which most browsers should > handle gracefully. >=20 > DNS connections (even zone transfers) are so short-lived that you > would have to be very, very lucky to pull off an insertion or RST > attack against. Yes, these seem to be stretches. > The most likely attack scenario to come out of this is probably gamers > and IRC weenies kicking eachother off servers (the server's IP address > and port number are known, the servers often reveal client IP > addresses to other clients, and the client often uses a fixed source > port, or one from a relatively small range) Every time someone is kicked off an IRC server (or otherwise restrained from online chat), global productivity rises :-) Cheers, --=20 Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd= .org From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 04:51:56 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FF6A16A4CE; Wed, 21 Apr 2004 04:51:56 -0700 (PDT) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2544443D54; Wed, 21 Apr 2004 04:51:56 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from localhost (localhost [127.0.0.1]) by gw.celabo.org (Postfix) with ESMTP id AC50754840; Wed, 21 Apr 2004 06:51:55 -0500 (CDT) Received: from gw.celabo.org ([127.0.0.1]) by localhost (hellblazer.celabo.org [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 84127-05; Wed, 21 Apr 2004 06:51:45 -0500 (CDT) Received: from lum.celabo.org (lum.celabo.org [10.0.1.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "lum.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id B9AE65487F; Wed, 21 Apr 2004 06:51:24 -0500 (CDT) Received: by lum.celabo.org (Postfix, from userid 501) id 779BF1D0B03; Wed, 21 Apr 2004 06:07:04 -0500 (CDT) Date: Wed, 21 Apr 2004 06:07:04 -0500 From: "Jacques A. Vidrine" To: Mike Silbersack Message-ID: <20040421110704.GA19640@lum.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Mike Silbersack , Don Lewis , freebsd-security@FreeBSD.org, avalon@caligula.anu.edu.au References: <200404210346.i3L3ki7E045504@gw.catspoiler.org> <20040421014736.H1228@odysseus.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040421014736.H1228@odysseus.silby.com> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: freebsd-security@FreeBSD.org cc: Don Lewis cc: avalon@caligula.anu.edu.au Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 11:51:56 -0000 On Wed, Apr 21, 2004 at 01:50:28AM -0500, Mike Silbersack wrote: > > On Tue, 20 Apr 2004, Don Lewis wrote: > > > I am concerned that step C will not solve the compatibility problem. The > > FreeBSD host is sending a FIN to close an established connection, and > > the peer host adding the window size advertised in the FIN packet to the > > sequence number acknowledged in the FIN packet, and using the sum as the > > sequence number for the RST packet, which puts the sequence number at > > the end of the receive window. > > Would it be feasible for us to create a four to five element array to > track "resettable" sequence numbers? This could hold the sequence numbers > of the last few packets transmitted, and account for that edge case as > well. I'm very uneasy with the IETF step C - sending more packets out > into the network sounds like a new type of amplification attack. I'm also somewhat skeptical. Considering the attack that this is supposed to mitigate, it would probably be a good idea to implement this as a compile time option defaulting OFF at first. Those really worried about an attack (running BGP?) can utilize it, as well as those testing interoperability for awhile. Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 04:52:07 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07E6216A4CE for ; Wed, 21 Apr 2004 04:52:07 -0700 (PDT) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5ECA43D2D for ; Wed, 21 Apr 2004 04:52:06 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from localhost (localhost [127.0.0.1]) by gw.celabo.org (Postfix) with ESMTP id 48AB9548A1; Wed, 21 Apr 2004 06:52:06 -0500 (CDT) Received: from gw.celabo.org ([127.0.0.1]) by localhost (hellblazer.celabo.org [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 84127-06; Wed, 21 Apr 2004 06:51:55 -0500 (CDT) Received: from lum.celabo.org (lum.celabo.org [10.0.1.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "lum.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id 4A7A354887; Wed, 21 Apr 2004 06:51:25 -0500 (CDT) Received: by lum.celabo.org (Postfix, from userid 501) id 63E691D0CA7; Wed, 21 Apr 2004 06:38:47 -0500 (CDT) Date: Wed, 21 Apr 2004 06:38:47 -0500 From: "Jacques A. Vidrine" To: Dragos Ruiu Message-ID: <20040421113847.GC19738@lum.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Dragos Ruiu , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , Mike Tancsa , freebsd-security@freebsd.org References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <200404201113.27737.dr@kyx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404201113.27737.dr@kyx.net> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: freebsd-security@freebsd.org cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Subject: Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 11:52:07 -0000 On Tue, Apr 20, 2004 at 11:13:27AM -0700, Dragos Ruiu wrote: > and we'll have some very sharp technical guys in the audience, including > some folks from very large ISPs that are most likely to be affected, I predict half will agree that this could be a serious issue, while the other half will claim it is absolutely a non-issue and will resent the first half for making them turn on MD5 auth on their BGP connections. :-) Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 04:52:17 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A60DB16A4CE for ; Wed, 21 Apr 2004 04:52:17 -0700 (PDT) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6134743D41 for ; Wed, 21 Apr 2004 04:52:17 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from localhost (localhost [127.0.0.1]) by gw.celabo.org (Postfix) with ESMTP id E3CD554898; Wed, 21 Apr 2004 06:52:16 -0500 (CDT) Received: from gw.celabo.org ([127.0.0.1]) by localhost (hellblazer.celabo.org [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 84127-07; Wed, 21 Apr 2004 06:52:06 -0500 (CDT) Received: from lum.celabo.org (lum.celabo.org [10.0.1.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "lum.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id 8FEEA54889; Wed, 21 Apr 2004 06:51:25 -0500 (CDT) Received: by lum.celabo.org (Postfix, from userid 501) id 2246E1D0C50; Wed, 21 Apr 2004 06:31:30 -0500 (CDT) Date: Wed, 21 Apr 2004 06:31:30 -0500 From: "Jacques A. Vidrine" To: Dragos Ruiu Message-ID: <20040421113130.GA19738@lum.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Dragos Ruiu , Mike Tancsa , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , freebsd-security@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404201332.40827.dr@kyx.net> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: freebsd-security@freebsd.org cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Subject: Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 11:52:17 -0000 On Tue, Apr 20, 2004 at 01:32:40PM -0700, Dragos Ruiu wrote: > That's what this thing boils down to imho - the > space you have to blast through, the time you have to do it in, and > the bandwidth/rate available to do it. And there are competing factors, > and questions about what are the real world values. I'm still waiting > on final answers... Consider that on a T1, you can generate 1536 Mbps = ~4800 RSTs per second. If you know ((src addr, src port), (dst addr, dst port)), and assume a 32K window, then you need to send at most about 2^17 RST packets to hit your target. 2^17 / 4800 =~ 27 seconds. If you have to guess the source port, then we're talking about 2^16 times as many packets needed, which is still `only' about 20 days. Of course, the window is sliding during that time... I'm not sure right now if that makes your chances better or worse :-) Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 06:24:34 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07C9916A4CE; Wed, 21 Apr 2004 06:24:34 -0700 (PDT) Received: from omgo.iij.ad.jp (omgo.iij.ad.jp [202.232.30.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FC3443D2D; Wed, 21 Apr 2004 06:24:33 -0700 (PDT) (envelope-from nagao@iij.ad.jp) Received: OMGO id i3LDOSsx019922; Wed, 21 Apr 2004 22:24:29 +0900 (JST) Received: OTM-MIX0 id i3LDOSGw014246; Wed, 21 Apr 2004 22:24:28 +0900 (JST) Received: JC-SMTP from localhost (kabosu.iij.ad.jp [192.168.187.105]) id i3LDORW6023292; Wed, 21 Apr 2004 22:24:28 +0900 (JST) Date: Wed, 21 Apr 2004 22:24:27 +0900 (JST) Message-Id: <20040421.222427.41675143.nagao@iij.ad.jp> To: nectar@freebsd.org From: Tadaaki Nagao In-Reply-To: <20040421111003.GB19640@lum.celabo.org> References: <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> <200404201332.40827.dr@kyx.net> <20040421111003.GB19640@lum.celabo.org> X-Mailer: Mew version 4.0.65 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-security@freebsd.org cc: des@des.no Subject: Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 13:24:34 -0000 In "Re: TCP RST attack", "Jacques A. Vidrine" wrote: > On Tue, Apr 20, 2004 at 01:32:40PM -0700, Dragos Ruiu wrote: > > Also keep in mind ports are predictable to varying degrees depending on > > the vendor or OS, which further reduces the brute force space you have to > > go though without sniffing. > > This is exactly why I ported OpenBSD's TCP ephemeral port allocation > randomization to FreeBSD-CURRENT (although I asked Mike Silby to commit > it for me and take the blame if it broke :-). It will also be MFC'd > shortly in time for 4.10-RELEASE. That sounds great! But a question arose in my mind... I think it'll improve FreeBSD as a client OS, but as a server OS it doesn't seem to help much (actually, any ;-). Is there any action planned to implement some kind of countermeasure for FreeBSD servers? Thanks, Tadaaki Nagao System Design and Development Division, Internet Initiative Japan Inc. From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 09:29:50 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 547D216A4CE; Wed, 21 Apr 2004 09:29:50 -0700 (PDT) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF1F343D58; Wed, 21 Apr 2004 09:29:49 -0700 (PDT) (envelope-from mike@sentex.net) Received: from avscan2.sentex.ca (avscan2.sentex.ca [199.212.134.19]) by smtp3.sentex.ca (8.12.11/8.12.10) with ESMTP id i3LGTkQt029031; Wed, 21 Apr 2004 12:29:46 -0400 (EDT) (envelope-from mike@sentex.net) Received: from localhost (localhost [127.0.0.1]) by avscan2.sentex.ca (Postfix) with ESMTP id EF19E59CA6; Wed, 21 Apr 2004 12:29:48 -0400 (EDT) Received: from avscan2.sentex.ca ([127.0.0.1]) by localhost (avscan2.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 04772-03; Wed, 21 Apr 2004 12:29:48 -0400 (EDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan2.sentex.ca (Postfix) with ESMTP id D6B6359CA4; Wed, 21 Apr 2004 12:29:48 -0400 (EDT) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id i3LGTjcV044159; Wed, 21 Apr 2004 12:29:45 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.0.3.0.0.20040421121715.04547510@209.112.4.2> X-Sender: mdtpop@209.112.4.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Wed, 21 Apr 2004 12:30:40 -0400 To: freebsd-security@FreeBSD.org From: Mike Tancsa In-Reply-To: <20040421111003.GB19640@lum.celabo.org> References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> <200404201332.40827.dr@kyx.net> <20040421111003.GB19640@lum.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at (avscan2) sentex.ca Subject: Other possible protection against RST/SYN attacks (was Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 16:29:50 -0000 One other technique that might help with respect to this attack is what Cisco implemented, commonly known as the "TTL hack" http://www.nanog.org/mtg-0302/hack.html I have not tried it yet, and I am not sure of the implications. But on bgp speaking hosts, what if the following were done. Assuming these are directly connected peers, sysctl -w net.inet.ip.ttl=255 ipfw add 500 allow tcp from any to me 179 ipttl 255 ipfw add 600 deny log tcp from any to me 179 You would also need to cover the source ports. Not sure what the cleanest looking rule for that would be. What nasty side effects would this cause ? If the attacker were on the same subnet this would not do anything, but you have larger problems if this is the case. ---Mike At 07:10 AM 21/04/2004, Jacques A. Vidrine wrote: >On Tue, Apr 20, 2004 at 01:32:40PM -0700, Dragos Ruiu wrote: > > Also keep in mind ports are predictable to varying degrees depending on > > the vendor or OS, which further reduces the brute force space you have to > > go though without sniffing. > >This is exactly why I ported OpenBSD's TCP ephemeral port allocation >randomization to FreeBSD-CURRENT (although I asked Mike Silby to commit >it for me and take the blame if it broke :-). It will also be MFC'd >shortly in time for 4.10-RELEASE. > >Cheers, >-- >Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 09:55:39 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14C5B16A4CE for ; Wed, 21 Apr 2004 09:55:39 -0700 (PDT) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCD7143D66 for ; Wed, 21 Apr 2004 09:55:38 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from localhost (localhost [127.0.0.1]) by gw.celabo.org (Postfix) with ESMTP id 2B55654846; Wed, 21 Apr 2004 11:55:38 -0500 (CDT) Received: from gw.celabo.org ([127.0.0.1]) by localhost (hellblazer.celabo.org [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 86835-01; Wed, 21 Apr 2004 11:55:27 -0500 (CDT) Received: from lum.celabo.org (lum.celabo.org [10.0.1.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "lum.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id 8B5C75482B; Wed, 21 Apr 2004 11:55:27 -0500 (CDT) Received: by lum.celabo.org (Postfix, from userid 501) id F2CAA1D168B; Wed, 21 Apr 2004 11:54:54 -0500 (CDT) Date: Wed, 21 Apr 2004 11:54:54 -0500 From: "Jacques A. Vidrine" To: Mike Tancsa Message-ID: <20040421165454.GB20049@lum.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Mike Tancsa , freebsd-security@FreeBSD.org References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> <200404201332.40827.dr@kyx.net> <20040421111003.GB19640@lum.celabo.org> <6.0.3.0.0.20040421121715.04547510@209.112.4.2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.3.0.0.20040421121715.04547510@209.112.4.2> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: freebsd-security@FreeBSD.org Subject: Re: Other possible protection against RST/SYN attacks (was Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 16:55:39 -0000 On Wed, Apr 21, 2004 at 12:30:40PM -0400, Mike Tancsa wrote: > > One other technique that might help with respect to this attack is what > Cisco implemented, commonly known as the "TTL hack" > > http://www.nanog.org/mtg-0302/hack.html More commonly known as GTSM and RFC 3682. Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 10:24:38 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5F2F16A4CE; Wed, 21 Apr 2004 10:24:38 -0700 (PDT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C3A843D53; Wed, 21 Apr 2004 10:24:38 -0700 (PDT) (envelope-from mike@sentex.net) Received: from avscan1.sentex.ca (avscan1.sentex.ca [199.212.134.11]) by smtp3b.sentex.ca (8.12.11/8.12.11) with ESMTP id i3LHObPE052164; Wed, 21 Apr 2004 13:24:37 -0400 (EDT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan1.sentex.ca (8.12.10/8.12.10) with ESMTP id i3LHOb3x026271; Wed, 21 Apr 2004 13:24:37 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id i3LHOaAe044360; Wed, 21 Apr 2004 13:24:36 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.0.3.0.0.20040421132605.0901bb40@209.112.4.2> X-Sender: mdtpop@209.112.4.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Wed, 21 Apr 2004 13:26:36 -0400 To: "Jacques A. Vidrine" From: Mike Tancsa In-Reply-To: <20040421165454.GB20049@lum.celabo.org> References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> <200404201332.40827.dr@kyx.net> <20040421111003.GB19640@lum.celabo.org> <6.0.3.0.0.20040421121715.04547510@209.112.4.2> <20040421165454.GB20049@lum.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new cc: freebsd-security@FreeBSD.org Subject: Re: Other possible protection against RST/SYN attacks (was Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 17:24:39 -0000 At 12:54 PM 21/04/2004, Jacques A. Vidrine wrote: >On Wed, Apr 21, 2004 at 12:30:40PM -0400, Mike Tancsa wrote: > > > > One other technique that might help with respect to this attack is what > > Cisco implemented, commonly known as the "TTL hack" > > > > http://www.nanog.org/mtg-0302/hack.html > >More commonly known as GTSM and RFC 3682. Are there any "bad things" that can happen by doing this ? ---Mike From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 11:21:33 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0C8B16A4CE for ; Wed, 21 Apr 2004 11:21:33 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 44AF943D39 for ; Wed, 21 Apr 2004 11:21:33 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 57586 invoked from network); 21 Apr 2004 18:21:31 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 21 Apr 2004 18:21:31 -0000 X-pair-Authenticated: 209.68.2.70 Date: Wed, 21 Apr 2004 13:47:35 -0500 (CDT) From: Mike Silbersack To: Don Lewis In-Reply-To: <200404211129.i3LBTH7E046516@gw.catspoiler.org> Message-ID: <20040421133638.S15588@odysseus.silby.com> References: <200404211129.i3LBTH7E046516@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-security@FreeBSD.org cc: avalon@caligula.anu.edu.au Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 18:21:33 -0000 On Wed, 21 Apr 2004, Don Lewis wrote: > On 21 Apr, Mike Silbersack wrote: > > Would it be feasible for us to create a four to five element array to > > track "resettable" sequence numbers? This could hold the sequence numbers > > of the last few packets transmitted, and account for that edge case as > > well. I'm very uneasy with the IETF step C - sending more packets out > > into the network sounds like a new type of amplification attack. > > I'd be concerned about the extra memory, especially in cases where we > want to support very large numbers of connections. I don't think the memory would be prohibitive, but upon further thought I don't think the idea is advantageous. > As far as amplification, step C has a gain of less than one, since > packets are only transmitted if the incoming packet hits the window, and > they will be the same or smaller in size than the incoming packets. I > don't know if it would be valid to rate limit them ... Good point, I had forgotten about that. However, I'm still worried that sending those acks could have a downside. With all the tcp stacks out there, it seems probable that something will go wrong. > If this is the only edge case that we have to worry about, we might be > able change the test to: > > if (th->th_seq == tp->last_ack_sent || > th->th_seq == tp->last_ack_sent + tp->rcv_wnd - 1) { Ok, what if we do something like this: 1. Accept all RSTs meeting the criteria you just listed above. 2. Keep a global counter of all out of window RSTs that were received which corresponded to legitimate connections. (Don't track _all_ RSTs, or backscatter from scanners / etc will falsely be detected as an attack.) If we're over a certain threshold, set the "under attack" flag. 2a. This counter could also be per-socket, with a very low threshold. (I think I like this better, actually.) 3. If a RST arrives within the window, check the under attack flag; if we're under attack, drop it. If we're not under attack, accept it. Add to a counter tracking how many of these we received and what we did with them. With this setup, any attempt to run the brute-force RST attack *should* fail, unless the attack gets lucky enough to have one of his first few packets land in the window. However, it should still let oddball TCP stacks RST connections, because they're presumably going to land within the window on the first packet. This would also be easy to implement. :) Thoughts? Mike "Silby" Silbersack From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 13:05:52 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64A8216A4CE for ; Wed, 21 Apr 2004 13:05:52 -0700 (PDT) Received: from orhi.sarenet.es (orhi.sarenet.es [192.148.167.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCA7B43D1D for ; Wed, 21 Apr 2004 13:05:51 -0700 (PDT) (envelope-from borjamar@sarenet.es) Received: from [192.168.2.3] (unknown [212.81.200.214]) by orhi.sarenet.es (Postfix) with ESMTP id 3841A7A30E6 for ; Wed, 21 Apr 2004 22:05:50 +0200 (MEST) Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: <6.0.3.0.0.20040421132605.0901bb40@209.112.4.2> References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> <200404201332.40827.dr@kyx.net> <20040421111003.GB19640@lum.celabo.org> <6.0.3.0.0.20040421121715.04547510@209.112.4.2> <20040421165454.GB20049@lum.celabo.org> <6.0.3.0.0.20040421132605.0901bb40@209.112.4.2> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <48FCF8AA-93CF-11D8-9C50-000393C94468@sarenet.es> Content-Transfer-Encoding: 7bit From: Borja Marcos Date: Wed, 21 Apr 2004 22:05:49 +0200 To: freebsd-security@freebsd.org X-Mailer: Apple Mail (2.613) Subject: Re: Other possible protection against RST/SYN attacks (was Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 20:05:52 -0000 > Are there any "bad things" that can happen by doing this ? Well, not every BGP sessions are established between directly connected interfaces. This would not work with "multi-hop BGP" sessions :-) Borja. From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 13:12:55 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C731116A4CE for ; Wed, 21 Apr 2004 13:12:55 -0700 (PDT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80CF343D49 for ; Wed, 21 Apr 2004 13:12:55 -0700 (PDT) (envelope-from mike@sentex.net) Received: from avscan1.sentex.ca (avscan1.sentex.ca [199.212.134.11]) by smtp3b.sentex.ca (8.12.11/8.12.11) with ESMTP id i3LKCor4076345; Wed, 21 Apr 2004 16:12:55 -0400 (EDT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan1.sentex.ca (8.12.10/8.12.10) with ESMTP id i3LKCn3x085545; Wed, 21 Apr 2004 16:12:49 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id i3LKCmiM045206; Wed, 21 Apr 2004 16:12:48 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.0.3.0.0.20040421161217.05453308@209.112.4.2> X-Sender: mdtpop@209.112.4.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Wed, 21 Apr 2004 16:14:46 -0400 To: Borja Marcos , freebsd-security@freebsd.org From: Mike Tancsa In-Reply-To: <48FCF8AA-93CF-11D8-9C50-000393C94468@sarenet.es> References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> <200404201332.40827.dr@kyx.net> <20040421111003.GB19640@lum.celabo.org> <6.0.3.0.0.20040421121715.04547510@209.112.4.2> <20040421165454.GB20049@lum.celabo.org> <6.0.3.0.0.20040421132605.0901bb40@209.112.4.2> <48FCF8AA-93CF-11D8-9C50-000393C94468@sarenet.es> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new Subject: Re: Other possible protection against RST/SYN attacks (was Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 20:12:55 -0000 At 04:05 PM 21/04/2004, Borja Marcos wrote: >>Are there any "bad things" that can happen by doing this ? > > Well, not every BGP sessions are established between directly > connected interfaces. This would not work with "multi-hop BGP" sessions :-) Thanks, I realize that, especially with iBGP. However for directly connected eBGP peers, the question still stands. What side effects if any are there? Why is the default 64 and not some other number like 255... I am sure the answer is out there, I just need to find the question so I can cram it into google ;-) Perhaps this is a better topic for freebsd-net ? ---Mike From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 13:20:28 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBCB516A564 for ; Wed, 21 Apr 2004 13:20:28 -0700 (PDT) Received: from orhi.sarenet.es (orhi.sarenet.es [192.148.167.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80B4143D1F for ; Wed, 21 Apr 2004 13:20:28 -0700 (PDT) (envelope-from borjamar@sarenet.es) Received: from [192.168.2.3] (unknown [212.81.200.214]) by orhi.sarenet.es (Postfix) with ESMTP id F14FE7A31A4; Wed, 21 Apr 2004 22:20:26 +0200 (MEST) In-Reply-To: <6.0.3.0.0.20040421161217.05453308@209.112.4.2> References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> <200404201332.40827.dr@kyx.net> <20040421111003.GB19640@lum.celabo.org> <6.0.3.0.0.20040421121715.04547510@209.112.4.2> <20040421165454.GB20049@lum.celabo.org> <6.0.3.0.0.20040421132605.0901bb40@209.112.4.2> <48FCF8AA-93CF-11D8-9C50-000393C94468@sarenet.es> <6.0.3.0.0.20040421161217.05453308@209.112.4.2> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <539B9B0C-93D1-11D8-9C50-000393C94468@sarenet.es> Content-Transfer-Encoding: 7bit From: Borja Marcos Date: Wed, 21 Apr 2004 22:20:26 +0200 To: Mike Tancsa X-Mailer: Apple Mail (2.613) cc: freebsd-security@freebsd.org Subject: Re: Other possible protection against RST/SYN attacks (was Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 20:20:28 -0000 > Thanks, I realize that, especially with iBGP. However for directly > connected eBGP peers, the question still stands. > > What side effects if any are there? Why is the default 64 and not > some other number like 255... I am sure the answer is out there, I > just need to find the question so I can cram it into google ;-) I can only think that it is a reasonable default. With a ttl of 200, for example, a routing loop would waste a lot of bandwidth for each undeliverable packet. Borja. From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 13:24:54 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6F1D16A4CE for ; Wed, 21 Apr 2004 13:24:54 -0700 (PDT) Received: from bergerie.agneau.org (bergerie.agneau.org [213.41.153.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE1D543D1F for ; Wed, 21 Apr 2004 13:24:53 -0700 (PDT) (envelope-from lolo@agneau.org) Received: from localhost (localhost [127.0.0.1]) by bergerie.agneau.org (Postfix) with ESMTP id 0FD5F43D for ; Wed, 21 Apr 2004 22:24:52 +0200 (CEST) Received: by bergerie.agneau.org (Postfix, from userid 500) id E096B43A; Wed, 21 Apr 2004 22:24:51 +0200 (CEST) Date: Wed, 21 Apr 2004 22:24:51 +0200 From: Laurent Frigault To: freebsd-security@freebsd.org Message-ID: <20040421202451.GA9515@obelix.bergerie.agneau.org> References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> <200404201332.40827.dr@kyx.net> <20040421111003.GB19640@lum.celabo.org> <6.0.3.0.0.20040421121715.04547510@209.112.4.2> <20040421165454.GB20049@lum.celabo.org> <6.0.3.0.0.20040421132605.0901bb40@209.112.4.2> <48FCF8AA-93CF-11D8-9C50-000393C94468@sarenet.es> <6.0.3.0.0.20040421161217.05453308@209.112.4.2> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <6.0.3.0.0.20040421161217.05453308@209.112.4.2> User-Agent: Mutt/1.4.2i X-Powered-By: UUCP X-Virus-Scanned: by amavisd-new at agneau.org Subject: Re: Other possible protection against RST/SYN attacks (was Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 20:24:54 -0000 On Wed, Apr 21, 2004 at 04:14:46PM -0400, Mike Tancsa wrote: > > Well, not every BGP sessions are established between directly > >connected interfaces. This would not work with "multi-hop BGP" sessions :-) > > Thanks, I realize that, especially with iBGP. However for directly > connected eBGP peers, the question still stands. Yes. This should be better handled by quagga/zebra . Regards, -- Laurent Frigault | If NT is the answer, you didn't understand the question. From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 13:35:49 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE67516A4CF for ; Wed, 21 Apr 2004 13:35:48 -0700 (PDT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA3EB43D45 for ; Wed, 21 Apr 2004 13:35:48 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i3LKZmZe022665; Wed, 21 Apr 2004 13:35:48 -0700 (PDT) Received: from [10.1.1.193] (nfw2.codefab.com [199.103.21.225] (may be forged)) (authenticated bits=0)i3LKZl3Z024557; Wed, 21 Apr 2004 13:35:47 -0700 (PDT) In-Reply-To: <6.0.3.0.0.20040421161217.05453308@209.112.4.2> References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> <200404201332.40827.dr@kyx.net> <20040421111003.GB19640@lum.celabo.org> <6.0.3.0.0.20040421121715.04547510@209.112.4.2> <20040421165454.GB20049@lum.celabo.org> <6.0.3.0.0.20040421132605.0901bb40@209.112.4.2> <48FCF8AA-93CF-11D8-9C50-000393C94468@sarenet.es> <6.0.3.0.0.20040421161217.05453308@209.112.4.2> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <75226E9B-93D3-11D8-90F9-003065ABFD92@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Wed, 21 Apr 2004 16:35:41 -0400 To: Mike Tancsa X-Mailer: Apple Mail (2.613) cc: freebsd-security@freebsd.org Subject: Re: Other possible protection against RST/SYN attacks (was Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 20:35:49 -0000 On Apr 21, 2004, at 4:14 PM, Mike Tancsa wrote: > What side effects if any are there? Why is the default 64 and not > some other number like 255... The default TTL gets decremented with every hop, which means that a packet coming in with a TTL of 255 had to be sent by a directly connected system. [ip_ttl is an octet, so it can't hold a larger TTL value.] A packet with a TTL of 64 could have been many hops away. -- -Chuck From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 13:41:55 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4F3616A4CE for ; Wed, 21 Apr 2004 13:41:55 -0700 (PDT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8CD543D49 for ; Wed, 21 Apr 2004 13:41:55 -0700 (PDT) (envelope-from mike@sentex.net) Received: from avscan1.sentex.ca (avscan1.sentex.ca [199.212.134.11]) by smtp3b.sentex.ca (8.12.11/8.12.11) with ESMTP id i3LKftY8079523; Wed, 21 Apr 2004 16:41:55 -0400 (EDT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan1.sentex.ca (8.12.10/8.12.10) with ESMTP id i3LKfs3x095048; Wed, 21 Apr 2004 16:41:54 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id i3LKfssb045439; Wed, 21 Apr 2004 16:41:54 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.0.3.0.0.20040421163904.0738d960@209.112.4.2> X-Sender: mdtpop@209.112.4.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Wed, 21 Apr 2004 16:43:48 -0400 To: Charles Swiger From: Mike Tancsa In-Reply-To: <75226E9B-93D3-11D8-90F9-003065ABFD92@mac.com> References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> <200404201332.40827.dr@kyx.net> <20040421111003.GB19640@lum.celabo.org> <6.0.3.0.0.20040421121715.04547510@209.112.4.2> <20040421165454.GB20049@lum.celabo.org> <6.0.3.0.0.20040421132605.0901bb40@209.112.4.2> <48FCF8AA-93CF-11D8-9C50-000393C94468@sarenet.es> <6.0.3.0.0.20040421161217.05453308@209.112.4.2> <75226E9B-93D3-11D8-90F9-003065ABFD92@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new cc: freebsd-security@freebsd.org Subject: Re: Other possible protection against RST/SYN attacks (was Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 20:41:56 -0000 At 04:35 PM 21/04/2004, Charles Swiger wrote: >On Apr 21, 2004, at 4:14 PM, Mike Tancsa wrote: >>What side effects if any are there? Why is the default 64 and not some >>other number like 255... > >The default TTL gets decremented with every hop, which means that a packet >coming in with a TTL of 255 had to be sent by a directly connected >system. [ip_ttl is an octet, so it can't hold a larger TTL value.] A >packet with a TTL of 64 could have been many hops away. Thanks, I realize that. My question is, what unintended consequences might happen if the default is changed to 255 from 64. As one poster said, if a packet generated by that host had a ttl of 255, it would bounce around a lot more if it was trying to reach a host with a bad route somewhere. I am no IP expert, but I have been around long enough to know that these default values get set only after long arduous debates and often there are tradeoffs by raising or lowering a value. I guess I am trying to find that original debate to see what I might be in for by implementing this with my peers who request it. ---Mike From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 14:01:45 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A79516A4CE for ; Wed, 21 Apr 2004 14:01:45 -0700 (PDT) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id E946543D45 for ; Wed, 21 Apr 2004 14:01:44 -0700 (PDT) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id D7D7D530A; Wed, 21 Apr 2004 23:01:43 +0200 (CEST) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 2CF8F5309; Wed, 21 Apr 2004 23:01:37 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 2602) id 0D9CF33C71; Wed, 21 Apr 2004 23:01:37 +0200 (CEST) To: Mike Tancsa References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> <200404201332.40827.dr@kyx.net> <20040421111003.GB19640@lum.celabo.org> <6.0.3.0.0.20040421121715.04547510@209.112.4.2> <20040421165454.GB20049@lum.celabo.org> <6.0.3.0.0.20040421132605.0901bb40@209.112.4.2> <48FCF8AA-93CF-11D8-9C50-000393C94468@sarenet.es> <6.0.3.0.0.20040421161217.05453308@209.112.4.2> <75226E9B-93D3-11D8-90F9-003065ABFD92@mac.com> <6.0.3.0.0.20040421163904.0738d960@209.112.4.2> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Wed, 21 Apr 2004 23:01:36 +0200 In-Reply-To: <6.0.3.0.0.20040421163904.0738d960@209.112.4.2> (Mike Tancsa's message of "Wed, 21 Apr 2004 16:43:48 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: freebsd-security@freebsd.org Subject: Re: Other possible protection against RST/SYN attacks (was Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 21:01:45 -0000 Mike Tancsa writes: > I am no IP expert, but I have been around long enough to know that > these default values get set only after long arduous debates and often > there are tradeoffs by raising or lowering a value. I guess I am > trying to find that original debate to see what I might be in for by > implementing this with my peers who request it. I think the default ttl of 64 was an arbitrary choice. You would probably be fine using 32, but any lower than that and you would start having trouble crossing oceans. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 14:16:17 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA62D16A4CE for ; Wed, 21 Apr 2004 14:16:17 -0700 (PDT) Received: from pursued-with.net (adsl-66-125-9-242.dsl.sndg02.pacbell.net [66.125.9.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35F2643D48 for ; Wed, 21 Apr 2004 14:16:15 -0700 (PDT) (envelope-from Kevin_Stevens@pursued-with.net) Received: from babelfish.pursued-with.net (babelfish.pursued-with.net [192.168.168.42]) by pursued-with.net (Postfix) with ESMTP id 4D28510482A for ; Wed, 21 Apr 2004 14:16:31 -0700 (PDT) Date: Wed, 21 Apr 2004 14:16:31 -0700 (PDT) From: Kevin Stevens To: freebsd-security@freebsd.org In-Reply-To: Message-ID: References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <200404201332.40827.dr@kyx.net> <6.0.3.0.0.20040421121715.04547510@209.112.4.2> <6.0.3.0.0.20040421132605.0901bb40@209.112.4.2> <6.0.3.0.0.20040421161217.05453308@209.112.4.2> <6.0.3.0.0.20040421163904.0738d960@209.112.4.2> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Subject: Re: Other possible protection against RST/SYN attacks (was Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Kevin_Stevens@pursued-with.net List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 21:16:17 -0000 On Wed, 21 Apr 2004, [iso-8859-1] Dag-Erling Sm=F8rgrav wrote: > Mike Tancsa writes: > I think the default ttl of 64 was an arbitrary choice. You would > probably be fine using 32, but any lower than that and you would start > having trouble crossing oceans. ?? Because of all the router buoys floating around?? KeS From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 14:18:19 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2156016A4CE for ; Wed, 21 Apr 2004 14:18:19 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF83643D45 for ; Wed, 21 Apr 2004 14:18:18 -0700 (PDT) (envelope-from garycor@comcast.net) Received: from comcast.net (pcp09118143pcs.union01.nj.comcast.net[69.142.234.88]) by comcast.net (rwcrmhc13) with SMTP id <2004042121181701500q1fete> (Authid: garycor); Wed, 21 Apr 2004 21:18:18 +0000 Message-ID: <4086E522.7090303@comcast.net> Date: Wed, 21 Apr 2004 17:18:26 -0400 From: Gary Corcoran User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charles Swiger References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> <200404201332.40827.dr@kyx.net> <20040421111003.GB19640@lum.celabo.org> <6.0.3.0.0.20040421121715.04547510@209.112.4.2> <20040421165454.GB20049@lum.celabo.org> <6.0.3.0.0.20040421132605.0901bb40@209.112.4.2> <48FCF8AA-93CF-11D8-9C50-000393C94468@sarenet.es> <6.0.3.0.0.20040421161217.05453308@209.112.4.2> <75226E9B-93D3-11D8-90F9-003065ABFD92@mac.com> In-Reply-To: <75226E9B-93D3-11D8-90F9-003065ABFD92@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-security@freebsd.org Subject: Re: Other possible protection against RST/SYN attacks (was Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 21:18:19 -0000 Charles Swiger wrote: > On Apr 21, 2004, at 4:14 PM, Mike Tancsa wrote: > >> What side effects if any are there? Why is the default 64 and not >> some other number like 255... > > > The default TTL gets decremented with every hop, which means that a > packet coming in with a TTL of 255 had to be sent by a directly > connected system. [ip_ttl is an octet, so it can't hold a larger TTL > value.] Huh? 255-- == 254, not 0. A TTL of 255 just allows the maximum possible number of hops, before being declared hopelessly lost. > A packet with a TTL of 64 could have been many hops away. As DES said in a later reply, 64 was probably just a reasonable, but arbitrary value. Whereas 255 would probably allow for several trips around the world, and would be overkill. Gary From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 14:34:11 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8537116A4CE for ; Wed, 21 Apr 2004 14:34:11 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0901343D4C for ; Wed, 21 Apr 2004 14:34:11 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i3LLXu7E047699; Wed, 21 Apr 2004 14:33:59 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200404212133.i3LLXu7E047699@gw.catspoiler.org> Date: Wed, 21 Apr 2004 14:33:55 -0700 (PDT) From: Don Lewis To: silby@silby.com In-Reply-To: <20040421133638.S15588@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-security@FreeBSD.org cc: avalon@caligula.anu.edu.au Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 21:34:11 -0000 On 21 Apr, Mike Silbersack wrote: > > > On Wed, 21 Apr 2004, Don Lewis wrote: > >> On 21 Apr, Mike Silbersack wrote: > >> > Would it be feasible for us to create a four to five element array to >> > track "resettable" sequence numbers? This could hold the sequence numbers >> > of the last few packets transmitted, and account for that edge case as >> > well. I'm very uneasy with the IETF step C - sending more packets out >> > into the network sounds like a new type of amplification attack. >> >> I'd be concerned about the extra memory, especially in cases where we >> want to support very large numbers of connections. > > I don't think the memory would be prohibitive, but upon further thought I > don't think the idea is advantageous. > >> As far as amplification, step C has a gain of less than one, since >> packets are only transmitted if the incoming packet hits the window, and >> they will be the same or smaller in size than the incoming packets. I >> don't know if it would be valid to rate limit them ... > > Good point, I had forgotten about that. However, I'm still worried that > sending those acks could have a downside. With all the tcp stacks out > there, it seems probable that something will go wrong. > >> If this is the only edge case that we have to worry about, we might be >> able change the test to: >> >> if (th->th_seq == tp->last_ack_sent || >> th->th_seq == tp->last_ack_sent + tp->rcv_wnd - 1) { > > Ok, what if we do something like this: > > 1. Accept all RSTs meeting the criteria you just listed above. At this step, it would be better if we used the window size that was advertised it the last packet sent, since that is what the sequence number of the RST packet will be calculated from, while the window size could have increased if data was consumed from the receive queue between the time we sent the last packet and when we received the RST. It doesn't look like we keep the necessary data for this. Probably the easiest thing to do would be to calculate the expected sequence number in tcp_output() and stash it in the pcb. > 2. Keep a global counter of all out of window RSTs that were received > which corresponded to legitimate connections. (Don't track _all_ RSTs, or > backscatter from scanners / etc will falsely be detected as an attack.) > If we're over a certain threshold, set the "under attack" flag. > > 2a. This counter could also be per-socket, with a very low threshold. (I > think I like this better, actually.) > > 3. If a RST arrives within the window, check the under attack flag; if > we're under attack, drop it. If we're not under attack, accept it. Add > to a counter tracking how many of these we received and what we did with > them. > > With this setup, any attempt to run the brute-force RST attack *should* > fail, unless the attack gets lucky enough to have one of his first few > packets land in the window. However, it should still let oddball TCP > stacks RST connections, because they're presumably going to land within > the window on the first packet. > > This would also be easy to implement. :) > > Thoughts? It would be nice to be able to age invalid RST packets so that things go back to normal when an attack ends, but this might enable slow speed attacks. We have to be careful not to falsely trigger the attack code if we ever decrease the window size. RST packets with sequence numbers lower than (to the left of) the window can be expected under normal circumstances if there are a number of packets in flight when the peer decides to drop the connection. This should not trigger a global attack status. Trigger a per-socket attack status should be ok, because if the RST packets are legitimate, they should trip the exact match test. From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 14:44:46 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27E2316A4CE for ; Wed, 21 Apr 2004 14:44:46 -0700 (PDT) Received: from mail.seekingfire.com (coyote.seekingfire.com [24.72.10.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC55743D4C for ; Wed, 21 Apr 2004 14:44:45 -0700 (PDT) (envelope-from tillman@seekingfire.com) Received: by mail.seekingfire.com (Postfix, from userid 500) id 740AE58A; Wed, 21 Apr 2004 15:44:45 -0600 (CST) Date: Wed, 21 Apr 2004 15:44:45 -0600 From: Tillman Hodgson To: freebsd-security@freebsd.org Message-ID: <20040421214445.GX476@seekingfire.com> References: <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> <200404201332.40827.dr@kyx.net> <20040421111003.GB19640@lum.celabo.org> <6.0.3.0.0.20040421121715.04547510@209.112.4.2> <20040421165454.GB20049@lum.celabo.org> <6.0.3.0.0.20040421132605.0901bb40@209.112.4.2> <48FCF8AA-93CF-11D8-9C50-000393C94468@sarenet.es> <6.0.3.0.0.20040421161217.05453308@209.112.4.2> <75226E9B-93D3-11D8-90F9-003065ABFD92@mac.com> <4086E522.7090303@comcast.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Wb5NtZlyOqqy58h0" Content-Disposition: inline In-Reply-To: <4086E522.7090303@comcast.net> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-GPG-Key-ID: 828AFC7B X-GPG-Fingerprint: 5584 14BA C9EB 1524 0E68 F543 0F0A 7FBC 828A FC7B X-GPG-Key: http://www.seekingfire.com/gpg_key.asc X-Urban-Legend: There is lots of hidden information in headers User-Agent: Mutt/1.5.6i Subject: Re: Other possible protection against RST/SYN attacks (was Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 21:44:46 -0000 --Wb5NtZlyOqqy58h0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 21, 2004 at 05:18:26PM -0400, Gary Corcoran wrote: > Charles Swiger wrote: > >The default TTL gets decremented with every hop, which means that a=20 > >packet coming in with a TTL of 255 had to be sent by a directly=20 > >connected system. [ip_ttl is an octet, so it can't hold a larger TTL=20 > >value.] >=20 > Huh? 255-- =3D=3D 254, not 0. A TTL of 255 just allows the maximum poss= ible > number of hops, before being declared hopelessly lost. Exactly -- if you see an incoming packet with a TTL of 255, it must've originated on a directly connected system /or it would've already been decremented to 254 or lower/. -T --=20 "Beware of he who would deny you information, for in his heart he dreams himself your master." --Wb5NtZlyOqqy58h0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAhutNDwp/vIKK/HsRAoN3AJ0aKDv4X5/wMIdY77mS8vzUnpKD8wCdHc7c ulf/IN+izwlMLk5BxDiDw40= =qlpc -----END PGP SIGNATURE----- --Wb5NtZlyOqqy58h0-- From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 14:55:05 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E73516A4CE for ; Wed, 21 Apr 2004 14:55:05 -0700 (PDT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4507E43D41 for ; Wed, 21 Apr 2004 14:55:05 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i3LLt45l001900; Wed, 21 Apr 2004 14:55:04 -0700 (PDT) Received: from [10.1.1.193] (nfw2.codefab.com [199.103.21.225] (may be forged)) (authenticated bits=0)i3LLt33Z022367; Wed, 21 Apr 2004 14:55:03 -0700 (PDT) In-Reply-To: <6.0.3.0.0.20040421163904.0738d960@209.112.4.2> References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> <200404201332.40827.dr@kyx.net> <20040421111003.GB19640@lum.celabo.org> <6.0.3.0.0.20040421121715.04547510@209.112.4.2> <20040421165454.GB20049@lum.celabo.org> <6.0.3.0.0.20040421132605.0901bb40@209.112.4.2> <48FCF8AA-93CF-11D8-9C50-000393C94468@sarenet.es> <6.0.3.0.0.20040421161217.05453308@209.112.4.2> <75226E9B-93D3-11D8-90F9-003065ABFD92@mac.com> <6.0.3.0.0.20040421163904.0738d960@209.112.4.2> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8830A10E-93DE-11D8-90F9-003065ABFD92@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Wed, 21 Apr 2004 17:54:58 -0400 To: Mike Tancsa X-Mailer: Apple Mail (2.613) cc: freebsd-security@freebsd.org Subject: Re: Other possible protection against RST/SYN attacks (was Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 21:55:05 -0000 On Apr 21, 2004, at 4:43 PM, Mike Tancsa wrote: >> The default TTL gets decremented with every hop, which means that a >> packet coming in with a TTL of 255 had to be sent by a directly >> connected system. [ip_ttl is an octet, so it can't hold a larger TTL >> value.] A packet with a TTL of 64 could have been many hops away. > > Thanks, I realize that. My question is, what unintended consequences > might happen if the default is changed to 255 from 64. As one poster > said, if a packet generated by that host had a ttl of 255, it would > bounce around a lot more if it was trying to reach a host with a bad > route somewhere. Certainly true, but are we talking about changing the default TTL for FreeBSD, or only for routers running BGP where both sides agree to implement RFC-3682? I wouldn't expect a router to be initiating much traffic on it's own. > I am no IP expert, but I have been around long enough to know that > these default values get set only after long arduous debates and often > there are tradeoffs by raising or lowering a value. I guess I am > trying to find that original debate to see what I might be in for by > implementing this with my peers who request it. Changing the TTL to 255 means one should adjust the TCP MSL to ~4 minutes, rather than one minute. RFC-791 says: This field must be decreased at each point that the internet header is processed to reflect the time spent processing the datagram. Even if no local information is available on the time actually spent, the field must be decremented by 1. The time is measured in units of seconds (i.e. the value 1 means one second). Thus, the maximum time to live is 255 seconds or 4.25 minutes. Since every module that processes a datagram must decrease the TTL by at least one even if it process the datagram in less than a second, the TTL must be thought of only as an upper bound on the time a datagram may exist. The intention is to cause undeliverable datagrams to be discarded, and to bound the maximum datagram lifetime. Some higher level reliable connection protocols are based on assumptions that old duplicate datagrams will not arrive after a certain time elapses. The TTL is a way for such protocols to have an assurance that their assumption is met. RFC-793 says: To be sure that a TCP does not create a segment that carries a sequence number which may be duplicated by an old segment remaining in the network, the TCP must keep quiet for a maximum segment lifetime (MSL) before assigning any sequence numbers upon starting up or recovering from a crash in which memory of sequence numbers in use was lost. For this specification the MSL is taken to be 2 minutes. This is an engineering choice, and may be changed if experience indicates it is desirable to do so. Note that if a TCP is reinitialized in some sense, yet retains its memory of sequence numbers in use, then it need not wait at all; it must only be sure to use sequence numbers larger than those recently used. -- -Chuck From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 14:59:43 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5964916A4CE for ; Wed, 21 Apr 2004 14:59:43 -0700 (PDT) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2761843D55 for ; Wed, 21 Apr 2004 14:59:43 -0700 (PDT) (envelope-from garycor@comcast.net) Received: from comcast.net (pcp09118143pcs.union01.nj.comcast.net[69.142.234.88]) by comcast.net (rwcrmhc12) with SMTP id <2004042121594201400i4dfne> (Authid: garycor); Wed, 21 Apr 2004 21:59:42 +0000 Message-ID: <4086EED7.3070808@comcast.net> Date: Wed, 21 Apr 2004 17:59:51 -0400 From: Gary Corcoran User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tillman Hodgson References: <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> <200404201332.40827.dr@kyx.net> <20040421111003.GB19640@lum.celabo.org> <6.0.3.0.0.20040421121715.04547510@209.112.4.2> <20040421165454.GB20049@lum.celabo.org> <6.0.3.0.0.20040421132605.0901bb40@209.112.4.2> <48FCF8AA-93CF-11D8-9C50-000393C94468@sarenet.es> <6.0.3.0.0.20040421161217.05453308@209.112.4.2> <75226E9B-93D3-11D8-90F9-003065ABFD92@mac.com> <4086E522.7090303@comcast.net> <20040421214445.GX476@seekingfire.com> In-Reply-To: <20040421214445.GX476@seekingfire.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-security@freebsd.org Subject: Re: Other possible protection against RST/SYN attacks (was Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 21:59:43 -0000 Tillman Hodgson wrote: > On Wed, Apr 21, 2004 at 05:18:26PM -0400, Gary Corcoran wrote: > >>Charles Swiger wrote: >> >>>The default TTL gets decremented with every hop, which means that a >>>packet coming in with a TTL of 255 had to be sent by a directly >>>connected system. [ip_ttl is an octet, so it can't hold a larger TTL >>>value.] >> >>Huh? 255-- == 254, not 0. A TTL of 255 just allows the maximum possible >>number of hops, before being declared hopelessly lost. > > > Exactly -- if you see an incoming packet with a TTL of 255, it must've > originated on a directly connected system /or it would've already been > decremented to 254 or lower/. Ah, yes, of course. I thought the original poster was implying that the packet could only exist on a direct connection, and wouldn't be passed along to another hop if it had a TTL of 255. But I guess I just got the wrong impression - sorry for the confusion. In any event, it still seems like 255 is overkill for this application... Gary From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 15:01:51 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BB3A16A4CE for ; Wed, 21 Apr 2004 15:01:51 -0700 (PDT) Received: from a.mx.ict1.everquick.net (a.mx.ict1.everquick.net [67.67.61.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B131343D1F for ; Wed, 21 Apr 2004 15:01:50 -0700 (PDT) (envelope-from eddy+public+spam@noc.everquick.net) Received: from a.mx.ict1.everquick.net (localhost [127.0.0.1]) i3LM1vAk022062; Wed, 21 Apr 2004 22:01:57 GMT X-EverQuick-No-Abuse: Report any e-mail abuse to Received: from localhost (eddy@localhost)i3LM1vfk022057; Wed, 21 Apr 2004 22:01:57 GMT X-Authentication-Warning: a.mx.ict1.everquick.net: eddy owned process doing -bs Date: Wed, 21 Apr 2004 22:01:57 +0000 (GMT) From: "E.B. Dreger" X-X-Sender: eddy@a.mx.ict1.everquick.net To: Mike Tancsa In-Reply-To: <6.0.3.0.0.20040421121715.04547510@209.112.4.2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-security@freebsd.org Subject: Re: Other possible protection against RST/SYN attacks (was Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 22:01:51 -0000 MT> Date: Wed, 21 Apr 2004 12:30:40 -0400 MT> From: Mike Tancsa MT> If the attacker were on the same subnet this would not do MT> anything, but you have larger problems if this is the case. Indeed. Anti-spoofing, per-switchport MAC restrictions, and hardcoded ARP entries for routers all go a long way toward improving security. :-) Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses : blacklist@brics.com -or- alfra@intc.net -or- curbjmp@intc.net Sending mail to spambait addresses is a great way to get blocked. From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 15:03:30 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D26816A4CE for ; Wed, 21 Apr 2004 15:03:30 -0700 (PDT) Received: from a.mx.ict1.everquick.net (a.mx.ict1.everquick.net [67.67.61.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA3B143D55 for ; Wed, 21 Apr 2004 15:03:29 -0700 (PDT) (envelope-from eddy+public+spam@noc.everquick.net) Received: from a.mx.ict1.everquick.net (localhost [127.0.0.1]) i3LM3ZAk022128; Wed, 21 Apr 2004 22:03:35 GMT X-EverQuick-No-Abuse: Report any e-mail abuse to Received: from localhost (eddy@localhost)i3LM3YI2022125; Wed, 21 Apr 2004 22:03:34 GMT X-Authentication-Warning: a.mx.ict1.everquick.net: eddy owned process doing -bs Date: Wed, 21 Apr 2004 22:03:34 +0000 (GMT) From: "E.B. Dreger" X-X-Sender: eddy@a.mx.ict1.everquick.net To: Gary Corcoran In-Reply-To: <4086EED7.3070808@comcast.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-security@freebsd.org Subject: Re: Other possible protection against RST/SYN attacks (was Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 22:03:30 -0000 GC> Date: Wed, 21 Apr 2004 17:59:51 -0400 GC> From: Gary Corcoran GC> In any event, it still seems like 255 is overkill for this GC> application... It isn't. Say you assumed TTL 128 instead of 255; received packets should have a TTL of 127. If I'm eleven hops away instead of one, I'll select a TTL of 138 to have the desired effect. Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses : blacklist@brics.com -or- alfra@intc.net -or- curbjmp@intc.net Sending mail to spambait addresses is a great way to get blocked. From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 15:10:21 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D995316A4CE for ; Wed, 21 Apr 2004 15:10:21 -0700 (PDT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0E1A43D45 for ; Wed, 21 Apr 2004 15:10:21 -0700 (PDT) (envelope-from garycor@comcast.net) Received: from comcast.net (pcp09118143pcs.union01.nj.comcast.net[69.142.234.88]) by comcast.net (rwcrmhc13) with SMTP id <2004042122102101500pv1nde> (Authid: garycor); Wed, 21 Apr 2004 22:10:21 +0000 Message-ID: <4086F156.7040808@comcast.net> Date: Wed, 21 Apr 2004 18:10:30 -0400 From: Gary Corcoran User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gary Corcoran , freebsd-security@freebsd.org References: <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> <200404201332.40827.dr@kyx.net> <20040421111003.GB19640@lum.celabo.org> <6.0.3.0.0.20040421121715.04547510@209.112.4.2> <20040421165454.GB20049@lum.celabo.org> <6.0.3.0.0.20040421132605.0901bb40@209.112.4.2> <48FCF8AA-93CF-11D8-9C50-000393C94468@sarenet.es> <6.0.3.0.0.20040421161217.05453308@209.112.4.2> <75226E9B-93D3-11D8-90F9-003065ABFD92@mac.com> <4086E522.7090303@comcast.net> <20040421214445.GX476@seekingfire.com> <4086EED7.3070808@comcast.net> In-Reply-To: <4086EED7.3070808@comcast.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Other possible protection against RST/SYN attacks (was Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 22:10:22 -0000 > In any event, it still seems like a TTL of 255 is overkill for this application... Unless, of course, you want to only accept packets with TTL of 255. This might be fine when both ends are setup to work this way. But it might break general interoperability... Gary From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 15:20:04 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B847E16A4CE for ; Wed, 21 Apr 2004 15:20:04 -0700 (PDT) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6573B43D48 for ; Wed, 21 Apr 2004 15:20:03 -0700 (PDT) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id 022CA5C7A0; Wed, 21 Apr 2004 15:20:03 -0700 (PDT) Date: Wed, 21 Apr 2004 15:20:02 -0700 From: Bill Fumerola To: Borja Marcos Message-ID: <20040421222002.GQ17862@elvis.mu.org> References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> <200404201332.40827.dr@kyx.net> <20040421111003.GB19640@lum.celabo.org> <6.0.3.0.0.20040421121715.04547510@209.112.4.2> <20040421165454.GB20049@lum.celabo.org> <6.0.3.0.0.20040421132605.0901bb40@209.112.4.2> <48FCF8AA-93CF-11D8-9C50-000393C94468@sarenet.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48FCF8AA-93CF-11D8-9C50-000393C94468@sarenet.es> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 4.10-MUORG-20040412 i386 X-PGP-Key: 1024D/7F868268 X-PGP-Fingerprint: 5B2D 908E 4C2B F253 DAEB FC01 8436 B70B 7F86 8268 cc: freebsd-security@freebsd.org Subject: Re: Other possible protection against RST/SYN attacks (was Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 22:20:04 -0000 On Wed, Apr 21, 2004 at 10:05:49PM +0200, Borja Marcos wrote: > >Are there any "bad things" that can happen by doing this ? > > Well, not every BGP sessions are established between directly > connected interfaces. This would not work with "multi-hop BGP" sessions GTSM works for multihop and this scenario is addressed in RFC3682. -- - bill fumerola / fumerola@yahoo-inc.com / billf@FreeBSD.org From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 16:17:20 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9F2916A4CF for ; Wed, 21 Apr 2004 16:17:20 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id EFA3443D58 for ; Wed, 21 Apr 2004 16:17:19 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 81736 invoked from network); 21 Apr 2004 23:17:18 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 21 Apr 2004 23:17:18 -0000 X-pair-Authenticated: 209.68.2.70 Date: Wed, 21 Apr 2004 18:52:03 -0500 (CDT) From: Mike Silbersack To: Don Lewis In-Reply-To: <200404212133.i3LLXu7E047699@gw.catspoiler.org> Message-ID: <20040421184539.H18583@odysseus.silby.com> References: <200404212133.i3LLXu7E047699@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-security@FreeBSD.org cc: avalon@caligula.anu.edu.au Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 23:17:21 -0000 On Wed, 21 Apr 2004, Don Lewis wrote: > > 1. Accept all RSTs meeting the criteria you just listed above. > > At this step, it would be better if we used the window size that was > advertised it the last packet sent, since that is what the sequence > number of the RST packet will be calculated from, while the window size > could have increased if data was consumed from the receive queue between > the time we sent the last packet and when we received the RST. > > It doesn't look like we keep the necessary data for this. Probably the > easiest thing to do would be to calculate the expected sequence number > in tcp_output() and stash it in the pcb. Do you have access to a system that exhibits the "RST at end of window" syndrome so that you could code up and test out this part of the patch? > It would be nice to be able to age invalid RST packets so that things go > back to normal when an attack ends, but this might enable slow speed > attacks. I think we can probably come up with something acceptable. If we just stop accepting RSTs for the next 30 seconds or so, that would significantly slow down the attack. Although slow speed attacks could still be possible, I don't see that as being too much of a risk. > We have to be careful not to falsely trigger the attack code if we ever > decrease the window size. > > RST packets with sequence numbers lower than (to the left of) the window > can be expected under normal circumstances if there are a number of > packets in flight when the peer decides to drop the connection. This > should not trigger a global attack status. Trigger a per-socket attack > status should be ok, because if the RST packets are legitimate, they > should trip the exact match test. We could make RST packets that are (left - window) not count towards the attack count, that should solve that problem. I think we have something that might work... Darren, PHK, etc - any comments? Mike "Silby" Silbersack From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 16:31:31 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0588316A4CE for ; Wed, 21 Apr 2004 16:31:30 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94F4843D41 for ; Wed, 21 Apr 2004 16:31:30 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i3LNVE7E047907; Wed, 21 Apr 2004 16:31:17 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200404212331.i3LNVE7E047907@gw.catspoiler.org> Date: Wed, 21 Apr 2004 16:31:14 -0700 (PDT) From: Don Lewis To: silby@silby.com, jayanth@yahoo-inc.com In-Reply-To: <20040421184539.H18583@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-security@FreeBSD.org cc: avalon@caligula.anu.edu.au Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 23:31:31 -0000 On 21 Apr, Mike Silbersack wrote: > > On Wed, 21 Apr 2004, Don Lewis wrote: > >> > 1. Accept all RSTs meeting the criteria you just listed above. >> >> At this step, it would be better if we used the window size that was >> advertised it the last packet sent, since that is what the sequence >> number of the RST packet will be calculated from, while the window size >> could have increased if data was consumed from the receive queue between >> the time we sent the last packet and when we received the RST. >> >> It doesn't look like we keep the necessary data for this. Probably the >> easiest thing to do would be to calculate the expected sequence number >> in tcp_output() and stash it in the pcb. > > Do you have access to a system that exhibits the "RST at end of window" > syndrome so that you could code up and test out this part of the patch? Nope. The only report of this that I saw was from jayanth. Judging by the tcpdump timestamps, it looks like whatever this wierd piece of hardware was, it was nearby. From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 17:30:55 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 610C916A4CE for ; Wed, 21 Apr 2004 17:30:55 -0700 (PDT) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E8CE43D2D for ; Wed, 21 Apr 2004 17:30:55 -0700 (PDT) (envelope-from mike@sentex.net) Received: from avscan2.sentex.ca (avscan2.sentex.ca [199.212.134.19]) by smtp3.sentex.ca (8.12.11/8.12.10) with ESMTP id i3M0UpSE095392; Wed, 21 Apr 2004 20:30:51 -0400 (EDT) (envelope-from mike@sentex.net) Received: from localhost (localhost [127.0.0.1]) by avscan2.sentex.ca (Postfix) with ESMTP id D7E2059C9A; Wed, 21 Apr 2004 20:30:52 -0400 (EDT) Received: from avscan2.sentex.ca ([127.0.0.1]) by localhost (avscan2.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 92108-12; Wed, 21 Apr 2004 20:30:52 -0400 (EDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan2.sentex.ca (Postfix) with ESMTP id C08D359C96; Wed, 21 Apr 2004 20:30:52 -0400 (EDT) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id i3M0UpIq045972; Wed, 21 Apr 2004 20:30:52 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.0.3.0.0.20040421202553.08107ad0@209.112.4.2> X-Sender: mdtpop@209.112.4.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 Date: Wed, 21 Apr 2004 20:32:32 -0400 To: freebsd-security@freebsd.org From: Mike Tancsa In-Reply-To: <4086F156.7040808@comcast.net> References: <6.0.3.0.0.20040420144001.0723ab80@209.112.4.2> <200404201332.40827.dr@kyx.net> <20040421111003.GB19640@lum.celabo.org> <6.0.3.0.0.20040421121715.04547510@209.112.4.2> <20040421165454.GB20049@lum.celabo.org> <6.0.3.0.0.20040421132605.0901bb40@209.112.4.2> <48FCF8AA-93CF-11D8-9C50-000393C94468@sarenet.es> <6.0.3.0.0.20040421161217.05453308@209.112.4.2> <75226E9B-93D3-11D8-90F9-003065ABFD92@mac.com> <4086E522.7090303@comcast.net> <20040421214445.GX476@seekingfire.com> <4086EED7.3070808@comcast.net> <4086F156.7040808@comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at (avscan2) sentex.ca Subject: Re: Other possible protection against RST/SYN attacks (was Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 00:30:55 -0000 At 06:10 PM 21/04/2004, Gary Corcoran wrote: >>In any event, it still seems like a TTL of 255 is overkill for this >>application... > >Unless, of course, you want to only accept packets with TTL >of 255. This might be fine when both ends are setup to work >this way. Yes, but thats the whole point of it. By having the 2 BGP speakers *only* accept packets that have a TTL of 255, you are safe to bet it has not come across another router as no one has decremented the TTL value. ---Mike From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 23:22:06 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CA8216A4D0 for ; Wed, 21 Apr 2004 23:22:06 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 69E7B43D31 for ; Wed, 21 Apr 2004 23:22:05 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 69910 invoked from network); 22 Apr 2004 06:22:04 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 22 Apr 2004 06:22:04 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 22 Apr 2004 01:28:20 -0500 (CDT) From: Mike Silbersack To: Don Lewis In-Reply-To: <200404212331.i3LNVE7E047907@gw.catspoiler.org> Message-ID: <20040422012305.Y19921@odysseus.silby.com> References: <200404212331.i3LNVE7E047907@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-security@FreeBSD.org cc: avalon@caligula.anu.edu.au cc: jayanth@yahoo-inc.com Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 06:22:06 -0000 On Wed, 21 Apr 2004, Don Lewis wrote: > On 21 Apr, Mike Silbersack wrote: > > Do you have access to a system that exhibits the "RST at end of window" > > syndrome so that you could code up and test out this part of the patch? > > Nope. The only report of this that I saw was from jayanth. Judging by > the tcpdump timestamps, it looks like whatever this wierd piece of > hardware was, it was nearby. Something just occured to me... we can just lump the "RST at end of window" case into the whole "RST somewhere in the window case". In that way, we only need two cases: 1. RSTs exactly at last_ack_sent (always accepted) 2. Everything else in the window (only accepted if "not under attack".) I could code up and test this over the weekend, if it sounds like a solution we're willing to go with. Mike "Silby" Silbersack From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 23:28:19 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F183416A4CE for ; Wed, 21 Apr 2004 23:28:19 -0700 (PDT) Received: from caligula.anu.edu.au (caligula.anu.edu.au [150.203.224.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DAE043D1D for ; Wed, 21 Apr 2004 23:28:19 -0700 (PDT) (envelope-from avalon@caligula.anu.edu.au) Received: from caligula.anu.edu.au (localhost [127.0.0.1]) by caligula.anu.edu.au (8.12.9/8.12.9) with ESMTP id i3M6SHbF017189; Thu, 22 Apr 2004 16:28:17 +1000 (EST) Received: (from avalon@localhost) by caligula.anu.edu.au (8.12.9/8.12.8/Submit) id i3M6SHVJ017187; Thu, 22 Apr 2004 16:28:17 +1000 (EST) From: Darren Reed Message-Id: <200404220628.i3M6SHVJ017187@caligula.anu.edu.au> To: silby@silby.com (Mike Silbersack) Date: Thu, 22 Apr 2004 16:28:17 +1000 (Australia/ACT) In-Reply-To: <20040422012305.Y19921@odysseus.silby.com> from "Mike Silbersack" at Apr 22, 2004 01:28:20 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-security@freebsd.org cc: jayanth@yahoo-inc.com Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 06:28:20 -0000 In some mail from Mike Silbersack, sie said: > On Wed, 21 Apr 2004, Don Lewis wrote: > > On 21 Apr, Mike Silbersack wrote: > > > Do you have access to a system that exhibits the "RST at end of window" > > > syndrome so that you could code up and test out this part of the patch? > > > > Nope. The only report of this that I saw was from jayanth. Judging by > > the tcpdump timestamps, it looks like whatever this wierd piece of > > hardware was, it was nearby. > > Something just occured to me... we can just lump the "RST at end of > window" case into the whole "RST somewhere in the window case". In that > way, we only need two cases: > > 1. RSTs exactly at last_ack_sent (always accepted) To pursue this thought further, if a FIN has been sent or received (connection has migrated from ESTABLISHED to CLOSE_WAIT or something else) then receiving an RST at this point should be much less of a problem, yes ? The only drawback is I've seen sessions where there's a last ditch attempt to get data through even though a FIN has been received. Darren From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 23:47:11 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6089616A4CE for ; Wed, 21 Apr 2004 23:47:11 -0700 (PDT) Received: from cray.e-card.bg (www.ahtopol-sunnyday.com [212.91.167.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FAA443D46 for ; Wed, 21 Apr 2004 23:47:10 -0700 (PDT) (envelope-from altares@cray.e-card.bg) Received: from cray.e-card.bg (localhost [127.0.0.1]) by cray.e-card.bg (8.12.9/8.12.9) with ESMTP id i3M6l9Um029692; Thu, 22 Apr 2004 09:47:09 +0300 (EEST) (envelope-from altares@cray.e-card.bg) Received: (from altares@localhost) by cray.e-card.bg (8.12.9/8.12.9/Submit) id i3M6l71c029691; Thu, 22 Apr 2004 09:47:07 +0300 (EEST) Date: Thu, 22 Apr 2004 09:47:07 +0300 From: Rumen Telbizov To: Mike Tancsa Message-ID: <20040422064707.GE8709@e-card.bg> References: <20040421165454.GB20049@lum.celabo.org> <6.0.3.0.0.20040421132605.0901bb40@209.112.4.2> <48FCF8AA-93CF-11D8-9C50-000393C94468@sarenet.es> <6.0.3.0.0.20040421161217.05453308@209.112.4.2> <75226E9B-93D3-11D8-90F9-003065ABFD92@mac.com> <4086E522.7090303@comcast.net> <20040421214445.GX476@seekingfire.com> <4086EED7.3070808@comcast.net> <4086F156.7040808@comcast.net> <6.0.3.0.0.20040421202553.08107ad0@209.112.4.2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.0.3.0.0.20040421202553.08107ad0@209.112.4.2> User-Agent: Mutt/1.4.2.1i cc: freebsd-security@freebsd.org Subject: Re: Other possible protection against RST/SYN attacks (was Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 06:47:11 -0000 Hi On Wed, Apr 21, 2004 at 08:32:32PM -0400, Mike Tancsa wrote: > At 06:10 PM 21/04/2004, Gary Corcoran wrote: > > >>In any event, it still seems like a TTL of 255 is overkill for this > >>application... > > > >Unless, of course, you want to only accept packets with TTL > >of 255. This might be fine when both ends are setup to work > >this way. > > Yes, but thats the whole point of it. By having the 2 BGP speakers *only* > accept packets that have a TTL of 255, you are safe to bet it has not come > across another router as no one has decremented the TTL value. > Just a comment on the topic: How about if _accidentally_ the routers are configured with the following option (or similar)? # IPSTEALTH enables code to support stealth forwarding (i.e., forwarding # packets without touching the ttl). This can be useful to hide firewalls # from traceroute and similar tools. If the packet has been generated with ttl == 255 it would arrive with ttl == 255 to you after all, if all the routers are using this option! Just a thought! Rumen Telbizov From owner-freebsd-security@FreeBSD.ORG Thu Apr 22 01:00:20 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C917A16A4D0 for ; Thu, 22 Apr 2004 01:00:20 -0700 (PDT) Received: from Neo-Vortex.Ath.Cx (203-173-23-17.dyn.iinet.net.au [203.173.23.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5EA843D4C for ; Thu, 22 Apr 2004 01:00:19 -0700 (PDT) (envelope-from root@Neo-Vortex.Ath.Cx) Received: from localhost.Neo-Vortex.got-root.cc (Neo-Vortex@localhost.Neo-Vortex.got-root.cc [127.0.0.1]) by Neo-Vortex.Ath.Cx (8.12.10/8.12.10) with ESMTP id i3M80GmR016739 for ; Thu, 22 Apr 2004 18:00:18 +1000 (EST) (envelope-from root@Neo-Vortex.Ath.Cx) Date: Thu, 22 Apr 2004 18:00:16 +1000 (EST) From: Neo-Vortex To: freebsd-security@freebsd.org In-Reply-To: <6.0.3.0.0.20040421132605.0901bb40@209.112.4.2> Message-ID: <20040422175239.E16696@Neo-Vortex.Ath.Cx> References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <200404201332.40827.dr@kyx.net> <6.0.3.0.0.20040421121715.04547510@209.112.4.2> <6.0.3.0.0.20040421132605.0901bb40@209.112.4.2> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Other possible protection against RST/SYN attacks X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 08:00:20 -0000 Heres my view on this hole thing and a solution to it: Take a step back from the problem, how is it caused? Spoofing of packets. Numerous vulnerabilities come from spoofed packets, and no doubt there will be more to come. If the ability to spoof packets on the internet was stopped, it would be much easier to fight such things, because they would not be possible. How to stop the spoofing? get ISPs to allow their customers to only send IP packets with the src address the same as their allocated ip(s) and drop the rest. If they all took the time to impliment this, they would not have to worry so much about patches later on because the probability of the packets being spoofed becomes so low. This could also be implimented on a higher level too (Asin the higher level ISPs doing similiar stuff) From owner-freebsd-security@FreeBSD.ORG Thu Apr 22 01:06:54 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A54516A4D0 for ; Thu, 22 Apr 2004 01:06:54 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id A46C143D46 for ; Thu, 22 Apr 2004 01:06:53 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 53051 invoked from network); 22 Apr 2004 08:06:52 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 22 Apr 2004 08:06:52 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 22 Apr 2004 03:16:12 -0500 (CDT) From: Mike Silbersack To: Darren Reed In-Reply-To: <200404220628.i3M6SHVJ017187@caligula.anu.edu.au> Message-ID: <20040422031525.E19921@odysseus.silby.com> References: <200404220628.i3M6SHVJ017187@caligula.anu.edu.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-security@freebsd.org cc: jayanth@yahoo-inc.com Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 08:06:54 -0000 On Thu, 22 Apr 2004, Darren Reed wrote: > > 1. RSTs exactly at last_ack_sent (always accepted) > > To pursue this thought further, if a FIN has been sent or received > (connection has migrated from ESTABLISHED to CLOSE_WAIT or something > else) then receiving an RST at this point should be much less of a > problem, yes ? > > The only drawback is I've seen sessions where there's a last ditch > attempt to get data through even though a FIN has been received. > > Darren Are you suggesting that we use the strict check during the ESTABLISHED phase, and the window-wide check during all other phases? Mike "Silby" Silbersack From owner-freebsd-security@FreeBSD.ORG Thu Apr 22 01:29:53 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D08416A4CE for ; Thu, 22 Apr 2004 01:29:53 -0700 (PDT) Received: from caligula.anu.edu.au (caligula.anu.edu.au [150.203.224.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1A4A43D49 for ; Thu, 22 Apr 2004 01:29:52 -0700 (PDT) (envelope-from avalon@caligula.anu.edu.au) Received: from caligula.anu.edu.au (localhost [127.0.0.1]) by caligula.anu.edu.au (8.12.9/8.12.9) with ESMTP id i3M8TpbF022692; Thu, 22 Apr 2004 18:29:51 +1000 (EST) Received: (from avalon@localhost) by caligula.anu.edu.au (8.12.9/8.12.8/Submit) id i3M8TpcB022690; Thu, 22 Apr 2004 18:29:51 +1000 (EST) From: Darren Reed Message-Id: <200404220829.i3M8TpcB022690@caligula.anu.edu.au> To: silby@silby.com (Mike Silbersack) Date: Thu, 22 Apr 2004 18:29:51 +1000 (Australia/ACT) In-Reply-To: <20040422031525.E19921@odysseus.silby.com> from "Mike Silbersack" at Apr 22, 2004 03:16:12 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-security@freebsd.org Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 08:29:53 -0000 In some mail from Mike Silbersack, sie said: > On Thu, 22 Apr 2004, Darren Reed wrote: > > > 1. RSTs exactly at last_ack_sent (always accepted) > > > > To pursue this thought further, if a FIN has been sent or received > > (connection has migrated from ESTABLISHED to CLOSE_WAIT or something > > else) then receiving an RST at this point should be much less of a > > problem, yes ? > > > > The only drawback is I've seen sessions where there's a last ditch > > attempt to get data through even though a FIN has been received. > > > > Darren > > Are you suggesting that we use the strict check during the ESTABLISHED > phase, and the window-wide check during all other phases? Possibly :) I don't think it is important for session setup, but at the end of a session, you generally want it to disappear from your connection table sooner rather than later, right ? Furthermore, you're more likely to get a RST after a FIN has been sent, by either party, if you send another ACK because the other guy has decided to remove the socket already. Does this make sense ? Although this makes me wonder, what's the implication here for FIN packets - is there none ? The draft refers to SYNs (which do get special treatment) and RSTs (just more violent FIN packets.) If someone injects a FIN packet the way they would have done a RST, what are the implications ? Does a packet storm ensue ? Does the FIN get ignored ? Do FIN packets also need to be challenge-responsed now ? Darren From owner-freebsd-security@FreeBSD.ORG Thu Apr 22 02:05:03 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3549C16A4CE for ; Thu, 22 Apr 2004 02:05:03 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id C438C43D39 for ; Thu, 22 Apr 2004 02:05:02 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 4909 invoked from network); 22 Apr 2004 09:05:01 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 22 Apr 2004 09:05:01 -0000 X-pair-Authenticated: 209.68.2.70 Date: Thu, 22 Apr 2004 04:16:03 -0500 (CDT) From: Mike Silbersack To: Darren Reed In-Reply-To: <200404220829.i3M8TpcB022690@caligula.anu.edu.au> Message-ID: <20040422041136.A21358@odysseus.silby.com> References: <200404220829.i3M8TpcB022690@caligula.anu.edu.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-security@freebsd.org Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 09:05:03 -0000 On Thu, 22 Apr 2004, Darren Reed wrote: > > Are you suggesting that we use the strict check during the ESTABLISHED > > phase, and the window-wide check during all other phases? > > Possibly :) > > I don't think it is important for session setup, but at the end of a > session, you generally want it to disappear from your connection table > sooner rather than later, right ? > > Furthermore, you're more likely to get a RST after a FIN has been > sent, by either party, if you send another ACK because the other > guy has decided to remove the socket already. Does this make > sense ? Yep, that makes sense. It would be very simple to implement as well. :) > Although this makes me wonder, what's the implication here for FIN > packets - is there none ? The draft refers to SYNs (which do get > special treatment) and RSTs (just more violent FIN packets.) > > If someone injects a FIN packet the way they would have done a RST, > what are the implications ? > Does a packet storm ensue ? > Does the FIN get ignored ? > Do FIN packets also need to be challenge-responsed now ? > > Darren I think that the third section of the draft covers this case when it talks about checking the sequence numbers in both directions for packets. Looks like we have a lot of testing to do. :| Mike "Silby" Silbersack From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 13:00:30 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F87E16A4DD for ; Tue, 20 Apr 2004 13:00:29 -0700 (PDT) Received: from staff.seccuris.com (staff.seccuris.com [204.112.0.40]) by mx1.FreeBSD.org (Postfix) with SMTP id 7C5ED43D48 for ; Tue, 20 Apr 2004 13:00:28 -0700 (PDT) (envelope-from maneo@bsdpro.com) Received: (qmail 52623 invoked by uid 1006); 20 Apr 2004 20:00:27 -0000 Date: Tue, 20 Apr 2004 20:00:27 +0000 From: "Christian S.J. Peron" To: Poul-Henning Kamp Message-ID: <20040420200027.A51891@staff.seccuris.com> References: <20040420015638.A84821@staff.seccuris.com> <14522.1082452837@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <14522.1082452837@critter.freebsd.dk>; from phk@phk.freebsd.dk on Tue, Apr 20, 2004 at 11:20:37AM +0200 X-Mailman-Approved-At: Thu, 22 Apr 2004 02:09:13 -0700 cc: freebsd-hackers@freebsd.org cc: freebsd-security@freebsd.org Subject: Re: [patch] Raw sockets in jails X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2004 20:00:30 -0000 Poul/group The following patch makes raw sockets comply with prison IP addresses. Some tools such as traceroute(8) may require that the prison IP address be specified on the command line. I.E. traceroute -s Otherwise it might fail. (because of this we may want to get rid of the create_raw_sockets MIB all together). Anyway, take a gander at it (testers feedback welcome): Regards Christian S.J. Peron --- sys/netinet/raw_ip.c.b Mon Apr 19 16:23:57 2004 +++ sys/netinet/raw_ip.c Tue Apr 20 19:43:30 2004 @@ -40,6 +40,7 @@ #include "opt_random_ip_id.h" #include +#include #include #include #include @@ -215,6 +216,11 @@ if (inp->inp_faddr.s_addr && inp->inp_faddr.s_addr != ip->ip_src.s_addr) goto docontinue; + if (inp->inp_socket->so_cred->cr_prison) { + if (htonl(inp->inp_socket->so_cred->cr_prison->pr_ip) + != ip->ip_dst.s_addr) + goto docontinue; + } if (last) { struct mbuf *n; @@ -270,7 +276,11 @@ ip->ip_off = 0; ip->ip_p = inp->inp_ip_p; ip->ip_len = m->m_pkthdr.len; - ip->ip_src = inp->inp_laddr; + if (inp->inp_socket->so_cred->cr_prison) + ip->ip_src.s_addr = + htonl(inp->inp_socket->so_cred->cr_prison->pr_ip); + else + ip->ip_src = inp->inp_laddr; ip->ip_dst.s_addr = dst; ip->ip_ttl = inp->inp_ip_ttl; } else { @@ -279,6 +289,13 @@ return(EMSGSIZE); } ip = mtod(m, struct ip *); + if (inp->inp_socket->so_cred->cr_prison) { + if (ip->ip_src.s_addr != + htonl(inp->inp_socket->so_cred->cr_prison->pr_ip)) { + m_freem(m); + return (EPERM); + } + } /* don't allow both user specified and setsockopt options, and don't allow packet length sizes that will crash */ if (((ip->ip_hl != (sizeof (*ip) >> 2)) @@ -505,6 +522,7 @@ } } +extern int jail_allow_raw_sockets; u_long rip_sendspace = RIPSNDQ; u_long rip_recvspace = RIPRCVQ; @@ -527,7 +545,11 @@ INP_INFO_WUNLOCK(&ripcbinfo); return EINVAL; } - if (td && (error = suser(td)) != 0) { + if (td && jailed(td->td_ucred) && !jail_allow_raw_sockets) { + INP_INFO_WUNLOCK(&ripcbinfo); + return (EPERM); + } + if (td && (error = suser_cred(td->td_ucred, PRISON_ROOT)) != 0) { INP_INFO_WUNLOCK(&ripcbinfo); return error; } @@ -626,6 +648,11 @@ if (nam->sa_len != sizeof(*addr)) return EINVAL; + + if (td->td_ucred->cr_prison) + if (htonl(td->td_ucred->cr_prison->pr_ip) + != addr->sin_addr.s_addr) + return (EADDRNOTAVAIL); if (TAILQ_EMPTY(&ifnet) || (addr->sin_family != AF_INET && addr->sin_family != AF_IMPLINK) || --- sys/kern/kern_jail.c.bak Mon Apr 19 16:55:40 2004 +++ sys/kern/kern_jail.c Mon Apr 19 17:56:03 2004 @@ -53,6 +53,11 @@ &jail_sysvipc_allowed, 0, "Processes in jail can use System V IPC primitives"); +int jail_allow_raw_sockets = 0; +SYSCTL_INT(_security_jail, OID_AUTO, allow_raw_sockets, CTLFLAG_RW, + &jail_allow_raw_sockets, 0, + "Prison root can create raw sockets"); + /* allprison, lastprid, and prisoncount are protected by allprison_mtx. */ struct prisonlist allprison; struct mtx allprison_mtx; On 20 Apr 2004 Poul-Henning Kamp wrote: > In message <20040420015638.A84821@staff.seccuris.com>, "Christian S.J. Peron" w > rites: > > > > Although RAW sockets can be used when specifying the source > > address of packets (defeating one of the aspects of the jail) > > some people may find it usefull to use utilities like ping(8) > > or traceroute(8) from inside jails. > > > > Enclosed is a patch I have written which gives you the option > > of allowing prison-root to create raw sockets inside the prison, > > so that programs various network debugging programs like ping > > and traceroute etc can be used. > > > > This patch will create the security.jail.allow_raw_sockets sysctl > > MIB. I would appriciate any feed-back from testers > > > > See PR #: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=65800 > > Could you take a peek and see how hard it would be to enforce source-IP > compliance with the jail restriction ? > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 05:10:57 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A95D16A4CE; Wed, 21 Apr 2004 05:10:57 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5513D43D45; Wed, 21 Apr 2004 05:10:57 -0700 (PDT) (envelope-from rrs@cisco.com) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 21 Apr 2004 04:22:39 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3LCAs7t001803; Wed, 21 Apr 2004 05:10:55 -0700 (PDT) Received: from cisco.com (rtp-dial-1-162.cisco.com [10.83.97.162]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATF32354; Wed, 21 Apr 2004 05:10:52 -0700 (PDT) Message-ID: <408664C4.3060100@cisco.com> Date: Wed, 21 Apr 2004 07:10:44 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Lewis References: <200404210346.i3L3ki7E045504@gw.catspoiler.org> In-Reply-To: <200404210346.i3L3ki7E045504@gw.catspoiler.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 22 Apr 2004 02:09:13 -0700 cc: freebsd-security@FreeBSD.org cc: avalon@caligula.anu.edu.au Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 12:10:57 -0000 Don Lewis wrote: >On 20 Apr, Don Lewis wrote: > > >>On 21 Apr, Darren Reed wrote: >> >> > > > >>>>http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt >>>> >>>> >>I saw this draft earlier today. >> >> RFC793 [1] currently requires handling of a segment with the RST bit >> when in a synchronized state to be processed as follows: >> 1) If the RST bit is set and the sequence number is outside the >> expected window, silently drop the segment. >> 2) If the RST bit is set and the sequence number is acceptable i.e.: >> (RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND) then reset the connection. >> >> >> Instead, the following changes should be made to provide some >> protection against such an attack. >> A) If the RST bit is set and the sequence number is outside the >> expected window, silently drop the segment. >> B) If the RST bit is exactly the next expected sequence number, reset >> the connection. >> C) If the RST bit is set and the sequence number does not exactly >> match the next expected sequence value, yet is within the >> acceptable window (RCV.NXT < SEG.SEQ <= RCV.NXT+RCV.WND) send an >> acknowledgment. >> >> >>Our original implementation of the RST sequence number checking was much >>more permissive than RFC 793. I submitted a patch, which was included >>in tcp_input.c version 1.81 that implemented steps A and B above. It >>was discovered that this is incompatible with certain peers, so the code >>was changed to match RFC 793 in tcp_input.c 1.98. >> >>I don't know if adding step C will fix the problem. There may further >>info in the list archives. >> >> > >>From what I see here: > >I am concerned that step C will not solve the compatibility problem. The >FreeBSD host is sending a FIN to close an established connection, and >the peer host adding the window size advertised in the FIN packet to the >sequence number acknowledged in the FIN packet, and using the sum as the >sequence number for the RST packet, which puts the sequence number at >the end of the receive window. > > > > Don: Hmm we tested this in many forms... the FIN packet should be accepted since it does not have the RST bit set... at least if I understand your concern properly... If I am not understanding it the most that will happen is you delay closing the connection an extra RTT... Now OpenBSD has had the RST fix in .. or something like it for a long time.. they will not accept a RST unless the sequence no matches.. they do NOT send an ACK to illicit a response as step C puts in... so... I don't see this harmful.. R -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c) From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 14:41:32 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D70F16A4CE for ; Wed, 21 Apr 2004 14:41:32 -0700 (PDT) Received: from fed1rmmtao01.cox.net (fed1rmmtao01.cox.net [68.230.241.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD4E643D31 for ; Wed, 21 Apr 2004 14:41:31 -0700 (PDT) (envelope-from mikeb@disturbed.org) Received: from pinky.disturbed.org ([68.98.45.46]) by fed1rmmtao01.cox.net ESMTP <20040421214131.GUYY8593.fed1rmmtao01.cox.net@pinky.disturbed.org>; Wed, 21 Apr 2004 17:41:31 -0400 Received: by pinky.disturbed.org (Postfix, from userid 1001) id CC40D6D5368; Wed, 21 Apr 2004 14:41:26 -0700 (MST) Date: Wed, 21 Apr 2004 14:41:26 -0700 From: Mike Benjamin To: Kevin Stevens Message-ID: <20040421214126.GA2503@disturbed.org> References: <6.0.3.0.0.20040420125557.06b10d48@209.112.4.2> <6.0.3.0.0.20040421121715.04547510@209.112.4.2> <6.0.3.0.0.20040421132605.0901bb40@209.112.4.2> <6.0.3.0.0.20040421161217.05453308@209.112.4.2> <6.0.3.0.0.20040421163904.0738d960@209.112.4.2> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.1i X-Mailman-Approved-At: Thu, 22 Apr 2004 02:09:13 -0700 cc: freebsd-security@freebsd.org Subject: Re: Other possible protection against RST/SYN attacks (was Re: TCP RST attack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 21:41:32 -0000 On Wed, Apr 21, 2004 at 02:16:31PM -0700, Kevin Stevens wrote: : : On Wed, 21 Apr 2004, [iso-8859-1] Dag-Erling Smørgrav wrote: : : > Mike Tancsa writes: : > I think the default ttl of 64 was an arbitrary choice. You would : > probably be fine using 32, but any lower than that and you would start : > having trouble crossing oceans. : : ?? Because of all the router buoys floating around?? Because hosts overseas tend to cross a greater distance, and packets traveling greater distances tend to cross more routers. This is not the rule, just a generalization. It is invalidated in some cases by MPLS LSPs being configured not to decrement TTL, and in others by the src and dst being in the same ASN, and even others who have a limited number of POPs which creates huge distances without ever breaking out at a l3 device. But, the generalization is still correct in most cases. A trace from my connection in the US to an arbitrary host in Finland gives me 28 hops (across 4 ASNs).. that's awfully close to 32. --mikeb : KeS : _______________________________________________ : freebsd-security@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-security : To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" -- Mike Benjamin = mikeb@mikeb.org From owner-freebsd-security@FreeBSD.ORG Thu Apr 22 02:21:54 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA3D116A4CE; Thu, 22 Apr 2004 02:21:54 -0700 (PDT) Received: from dragonfly.sitetronics.com (zp-c-13e65.mxs.adsl.euronet.nl [81.69.92.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79F3A43D60; Thu, 22 Apr 2004 02:21:53 -0700 (PDT) (envelope-from dodell@dragonfly.sitetronics.com) Received: from dragonfly.sitetronics.com (dragonfly [127.0.0.1]) i3MBLKhQ001102; Thu, 22 Apr 2004 11:21:20 GMT (envelope-from dodell@dragonfly.sitetronics.com) Received: (from dodell@localhost)i3MBLK9I001101; Thu, 22 Apr 2004 11:21:20 GMT (envelope-from dodell) Date: Thu, 22 Apr 2004 11:21:20 +0000 From: "Devon H. O'Dell" To: "Christian S.J. Peron" Message-ID: <20040422112120.GB888@sitetronics.com> References: <20040420015638.A84821@staff.seccuris.com> <14522.1082452837@critter.freebsd.dk> <20040420200027.A51891@staff.seccuris.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040420200027.A51891@staff.seccuris.com> User-Agent: Mutt/1.4.2.1i X-Mailer: Mutt 1.3.23i (2001-10-09) X-Editor: Vim http://www.vim.org/ cc: freebsd-hackers@freebsd.org cc: Poul-Henning Kamp cc: freebsd-security@freebsd.org Subject: Re: [patch] Raw sockets in jails X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 09:21:55 -0000 Christian S.J. Peron scribbled: > Poul/group > > The following patch makes raw sockets comply with prison IP addresses. > Some tools such as traceroute(8) may require that the prison IP address > be specified on the command line. I.E. > > traceroute -s > > Otherwise it might fail. > > (because of this we may want to get rid of the > create_raw_sockets MIB all together). > > Anyway, take a gander at it (testers feedback welcome): > > Regards > Christian S.J. Peron Nice work! It doesn't seem that it would be very difficult to get this to comply with Pawels multiple IPs in jail patch, but it would have to be optimized a bit as the IPs are currently stored in a linked list in his patch and traversing that list to determine whether the IP complies with the jails allotted IP range is sub-optimal (as it would have to be done on a per-packet basis). If we could store those IPs in a hash table with a fast algorithm for O(1) lookup times, the prison subsystem would experience significant feature improvements. -- Kind regards, Devon H. O'Dell | dodell@sitetronics.com ICQ: 2903604 | IRC: dho@freenode/dodell@efnet From owner-freebsd-security@FreeBSD.ORG Thu Apr 22 04:30:23 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4103116A4CF; Thu, 22 Apr 2004 04:30:23 -0700 (PDT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1462E43D2D; Thu, 22 Apr 2004 04:30:10 -0700 (PDT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id DCC39ACC5C; Thu, 22 Apr 2004 13:30:02 +0200 (CEST) Date: Thu, 22 Apr 2004 13:30:02 +0200 From: Pawel Jakub Dawidek To: "Christian S.J. Peron" Message-ID: <20040422113002.GW24376@darkness.comp.waw.pl> References: <20040420015638.A84821@staff.seccuris.com> <14522.1082452837@critter.freebsd.dk> <20040420200027.A51891@staff.seccuris.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5mjPmdht4ZehXHR2" Content-Disposition: inline In-Reply-To: <20040420200027.A51891@staff.seccuris.com> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: freebsd-hackers@freebsd.org cc: Poul-Henning Kamp cc: freebsd-security@freebsd.org Subject: Re: [patch] Raw sockets in jails X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 11:30:23 -0000 --5mjPmdht4ZehXHR2 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 20, 2004 at 08:00:27PM +0000, Christian S.J. Peron wrote: +> Poul/group +>=20 +> The following patch makes raw sockets comply with prison IP addresses. +> Some tools such as traceroute(8) may require that the prison IP address +> be specified on the command line. I.E. +>=20 +> traceroute -s +>=20 +> Otherwise it might fail. +>=20 +> (because of this we may want to get rid of the +> create_raw_sockets MIB all together). +>=20 +> Anyway, take a gander at it (testers feedback welcome): Looks very neat! I've merge your patch to my jail work (pjd_jail perforce branch) and changed it to be usable with my multiple ips stuff. I haven't reviewed nor tested it yet. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --5mjPmdht4ZehXHR2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAh6y6ForvXbEpPzQRArWBAKDKijJxa0MWetxMmwtuKgYgFYv6WQCgpL/W on2HykuapcHLa7EGsAhkxNM= =QbHT -----END PGP SIGNATURE----- --5mjPmdht4ZehXHR2-- From owner-freebsd-security@FreeBSD.ORG Thu Apr 22 04:55:31 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 596F016A4CE for ; Thu, 22 Apr 2004 04:55:31 -0700 (PDT) Received: from mail.xensia.net (colo1.xensia.net [217.158.173.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 642DB43D53 for ; Thu, 22 Apr 2004 04:55:30 -0700 (PDT) (envelope-from listsucker@ipv5.net) Received: from 81-174-2-199.f5.ngi.it ([81.174.2.199] helo=godzilla) by mail.xensia.net with asmtp (TLSv1:DES-CBC3-SHA:168) id 1BGcng-000Mbn-00; Thu, 22 Apr 2004 12:55:28 +0100 Date: Thu, 22 Apr 2004 13:51:12 +0200 From: Frankye - ML To: freebsd-security@freebsd.org Message-Id: <20040422135112.21abe234@godzilla> X-Mailer: Sylpheed version 0.9.10claws (GTK+ 1.2.10; i386-portbld-freebsd4.9) X-Face: =3I@Jvohf91[b8M]~KUNFaCt}pnTO2K^E#_P4`uCU]D"pHw Subject: Fw: [bugtraq] NetBSD Security Advisory 2004-006: TCP protocol and implementation vulnerability X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 11:55:31 -0000 The NetBSD folks just released some patches to mitigate the problem, maybe it can be of some help. Begin forwarded message: Date: Wed, 21 Apr 2004 14:14:35 -0400 From: NetBSD Security-Officer To: bugtraq@securityfocus.com Subject: NetBSD Security Advisory 2004-006: TCP protocol and implementation vulnerability -----BEGIN PGP SIGNED MESSAGE----- NetBSD Security Advisory 2004-006 ================================= Topic: TCP protocol and implementation vulnerability Version: NetBSD-current: source prior to April 22, 2004 NetBSD 2.0: branch affected, release will include the fix NetBSD 1.6.2: affected NetBSD 1.6.1: affected NetBSD 1.6: affected NetBSD-1.5.3: affected NetBSD-1.5.2: affected NetBSD-1.5.1: affected NetBSD-1.5: affected Severity: Serious (TCP disconnected by malicious party, unwanted data injected into TCP stream) Fixed: NetBSD-current: April 22, 2004 NetBSD-2.0 branch: April 22, 2004 NetBSD-1.6 branch: April 22, 2004 (1.6.3 will include the fix) NetBSD-1.5 branch: April 22, 2004 Abstract ======== The longstanding TCP protocol specification has several weaknesses. (RFC793): - - fabricated RST packets from a malicious third party can tear down a TCP session - - fabricated SYN packets from a malicious third party can tear down a TCP session - - a malicious third party can inject data to TCP session without much difficulty NetBSD also had an additional implementation flaw, which made these attacks easier. Technical Details ================= Under the current TCP protocol specification, it is impossible to make us perfectly secure against these vulnerabilities. Improvements have been made to reduce the probability of successful attacks. These improvements are based on the recently released Internet Draft, draft-ietf-tcpm-tcpsecure-00.txt Additionally, the 4.4BSD stack from which NetBSD's stack is derived, did not even check that a RST's sequence number was inside the window. RSTs anywhere to the left of the window were treated as valid. The fact that this has gone unnoticed for so long is an indication that there have not been a large number of RST/SYN DoS attacks ocurring in the wild. However, the widespread nature of the larger TCP issue will likely affect that trend. Note that security protocols on top of TCP such as SSH and SSL do not protect you from the DoS attack. These connections are also vulnerable to disconnection. However, since these protocols sign their payloads, data injection is not possible, though it could cause a disconnection as a side-effect of the attack. To use these attacks, the attacker must know the 5 tuple of the connection being targetted. On the server end, the IP and port are likely to be well-known. The IP and port of a client is more obscure. For systems which provide shell access to untrusted users, be aware that many system tools expose client IP and port information. Now that this issue is public, developers and users may wish to discuss if any of this information should be hidden by default. http://www.uniras.gov.uk/vuls/2004/236929/index.htm http://www.us-cert.gov/cas/techalerts/TA04-111A.html http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt Solutions and Workarounds ========================= All NetBSD systems that use TCP are affected. The only complete protection from this issue, is to use a security protocol which runs below the TCP layer, such as IPSec, or TCP-MD5. However, in practice, we believe the currently implemented improvements to the stack will prevent any serious impact of this issue. NetBSD includes support for IPSec. NetBSD does not include TCP-MD5 support at this time, though it is being integrated shortly. Regardless, TCP-MD5 is only particularly suitable for protecting BGP sessions over TCP, due to key management and cipher selection issues. Only a small percentage of systems run BGP. BGP system operators can prevent these attacks through ingress and egress filtering. BGP routers should not accept packets claiming to be from their BGP-peer, on interfaces other than those directly connected to that peer. BGP routers should not accept packets claiming to be from themselves, arriving on any external interface. These rules are easily implemented with the IP Filter functionality in NetBSD. Malicious parties create TCP packets with forged source addresses. If you already have configured ingress filtering, according to RFC3013, then your intranet TCP sessions are already protected. If not, consider adding it, as well as egress filtering, to prevent your users from forging source addresses to attack others. The following instructions describe how to upgrade your kernel binaries by updating your source tree and rebuilding and installing a new version of kernel. The new kernel makes the attacks much more difficult. * NetBSD-current: Systems running NetBSD-current dated from before 2004-04-21 should be upgraded to NetBSD-current dated 2004-04-22 or later. The following directories need to be updated from the netbsd-current CVS branch (aka HEAD): sys/netinet To update from CVS, re-build, and re-install the kernel: # cd src # cvs update -d -P sys/netinet # cd arch/ARCH/conf # config CONFIG # cd ../compile/CONFIG # make clean depend; make # cp netbsd / # reboot * NetBSD 1.6, 1.6.1, 1.6.2: The binary distribution of NetBSD 1.6, 1.6.1 and 1.6.2 are vulnerable. Systems running NetBSD 1.6 sources dated from before 2004-04-21 should be upgraded from NetBSD 1.6 sources dated 2004-04-22 or later. NetBSD 1.6.3 will include the fix. The following directories need to be updated from the netbsd-1-6 CVS branch: sys/netinet To update from CVS, re-build, and re-install the kernel: # cd src # cvs update -d -P -r netbsd-1-6 sys/netinet # cd arch/ARCH/conf # config CONFIG # cd ../compile/CONFIG # make clean depend; make # cp netbsd / # reboot * Binary Patch: *** The 1.6 kernels are being built. This text will be updated once they are available. The instructions are included here so that you can follow them once the patch directory is populated with a patch for your architecture. For the NetBSD-1-6 branch, binary patches are being provided, in the form of replacement kernels built with the patches from the GENERIC kernel configuration. If you use a custom kernel configuration, these may not be suitable for you. To apply the binary patch, perform the following steps, replacing ARCH with the NetBSD architecture you are running (i.e. i386): ftp://ftp.netbsd.org/pub/NetBSD/security/patches/SA2004-006-kernel/netbsd-1-6/ARCH-kernel.tgz cd / && cp /path/to/ARCH-kernel.gz / gzip -d ARCH-kernel.gz The tar file will extract a new copy of: ARCH-kernel Back up your old kernel: mv netbsd netbsd.old Then either rename: mv ARCH-kernel netbsd or link, as per local site policy: ln ARCH-kernel netbsd Then, reboot. * NetBSD 1.5, 1.5.1, 1.5.2, 1.5.3: The binary distribution of NetBSD 1.5 to 1.5.3 are vulnerable. Systems running NetBSD 1.5, 1.5.1, 1.5.2, or 1.5.3 sources dated from before 2004-04-21 should be upgraded from NetBSD 1.5.* sources dated 2004-04-22 or later. The following directories need to be updated from the netbsd-1-5 CVS branch: sys/netinet To update from CVS, re-build, and re-install the kernel: # cd src # cvs update -d -P -r netbsd-1-5 sys/netinet # cd arch/ARCH/conf # config CONFIG # cd ../compile/CONFIG # make clean depend; make # cp netbsd / # reboot Thanks To ========= NISCC JPCERT/CC Markus Friedl Randall Stewart Revision History ================ 2004-04-21 Initial release More Information ================ Advisories may be updated as new information becomes available. The most recent version of this advisory (PGP signed) can be found at ftp://ftp.NetBSD.org/pub/NetBSD/security/advisories/NetBSD-SA2004-006.txt.asc Information about NetBSD and NetBSD security can be found at http://www.NetBSD.org/ and http://www.NetBSD.org/Security/. Copyright 2004, The NetBSD Foundation, Inc. All Rights Reserved. Redistribution permitted only in full, unmodified form. $NetBSD: NetBSD-SA2004-006.txt,v 1.2 2004/04/21 17:34:50 david Exp $ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (NetBSD) iQCVAwUBQIax4j5Ru2/4N2IFAQGApAP/e2HLnCeKLc6iaJ/VNW/uJ9pH+iXFuS5a xT4NhV9YCyxAFKYlZjaanA0h3Nnedekk/FJpiVleb2I1el6sz7f4oQe8QhgnA6f/ jaINWUhkb9vmdhA0U629BWxCSHUzATEoTTXo2U5Onh4UTS2xBU+SmBc2DwhqXRB5 GS2zePuQpb0= =YiKd -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Thu Apr 22 05:11:57 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E7F616A4CE for ; Thu, 22 Apr 2004 05:11:57 -0700 (PDT) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 528F443D58 for ; Thu, 22 Apr 2004 05:11:57 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (not verified)) by gw.celabo.org (Postfix) with ESMTP id DDC4E5485D; Thu, 22 Apr 2004 07:11:56 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 8D29A6D479; Thu, 22 Apr 2004 07:11:56 -0500 (CDT) Date: Thu, 22 Apr 2004 07:11:56 -0500 From: "Jacques A. Vidrine" To: Frankye - ML Message-ID: <20040422121156.GC29225@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Frankye - ML , freebsd-security@freebsd.org References: <200404210158.i3L1wxoM010197@caligula.anu.edu.au> <20040422135112.21abe234@godzilla> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040422135112.21abe234@godzilla> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: freebsd-security@freebsd.org Subject: Re: Fw: [bugtraq] NetBSD Security Advisory 2004-006: TCP protocol and implementation vulnerability X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 12:11:57 -0000 On Thu, Apr 22, 2004 at 01:51:12PM +0200, Frankye - ML wrote: [...] > Additionally, the 4.4BSD stack from which NetBSD's stack is derived, did > not even check that a RST's sequence number was inside the window. RSTs > anywhere to the left of the window were treated as valid. > > The fact that this has gone unnoticed for so long is an indication that > there have not been a large number of RST/SYN DoS attacks ocurring in the > wild. Hmm, is this the same issue that we corrected in 1998? Certainly we became aware of it because it *was* being exploited. Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org From owner-freebsd-security@FreeBSD.ORG Thu Apr 22 05:38:59 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B938216A4CE for ; Thu, 22 Apr 2004 05:38:59 -0700 (PDT) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88FD343D39 for ; Thu, 22 Apr 2004 05:38:59 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (not verified)) by gw.celabo.org (Postfix) with ESMTP id 269FD54840; Thu, 22 Apr 2004 07:38:59 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id C7EC76D479; Thu, 22 Apr 2004 07:38:58 -0500 (CDT) Date: Thu, 22 Apr 2004 07:38:58 -0500 From: "Jacques A. Vidrine" To: Frankye - ML , freebsd-security@freebsd.org Message-ID: <20040422123858.GG29225@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Frankye - ML , freebsd-security@freebsd.org References: <200404210158.i3L1wxoM010197@caligula.anu.edu.au> <20040422135112.21abe234@godzilla> <20040422121156.GC29225@madman.celabo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040422121156.GC29225@madman.celabo.org> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i Subject: Re: Fw: [bugtraq] NetBSD Security Advisory 2004-006: TCP protocol and implementation vulnerability X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 12:38:59 -0000 Oh but to answer your implied question `does this help': NetBSD has implemented the IETF TCP Maintenance and Minor Extensions Working Group (tcpm-wg) TCP security considerations Internet-Draft, but as you can see from recent discussion on this list (or practically any other networking-related forum lately) implementing it as currently written could have negative effects. I'm counting on our networking guys ``doing the right thing.'' Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org From owner-freebsd-security@FreeBSD.ORG Thu Apr 22 11:35:26 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26A6E16A4CF for ; Thu, 22 Apr 2004 11:35:26 -0700 (PDT) Received: from staff.seccuris.com (staff.seccuris.com [204.112.0.40]) by mx1.FreeBSD.org (Postfix) with SMTP id 2067143D45 for ; Thu, 22 Apr 2004 11:35:25 -0700 (PDT) (envelope-from cperon-list@seccuris.com) Received: (qmail 24252 invoked by uid 1006); 22 Apr 2004 18:35:24 -0000 Date: Thu, 22 Apr 2004 18:35:24 +0000 From: "Christian S.J. Peron" To: Poul-Henning Kamp Message-ID: <20040422183523.A22252@staff.seccuris.com> References: <20040420200027.A51891@staff.seccuris.com> <23453.1082492678@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <23453.1082492678@critter.freebsd.dk>; from phk@phk.freebsd.dk on Tue, Apr 20, 2004 at 10:24:38PM +0200 cc: freebsd-hackers@freebsd.org cc: freebsd-security@freebsd.org Subject: Re: [patch] Raw sockets in jails X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 18:35:26 -0000 I discovered the reason why traceroute breaks without -s with the most recent patches I posted to the list. When traceroute can not figure out what its source IP address is, it generates a RTM_GET routing request through a routing socket and extracts the source address of the route given the destination. I have created a new set of patches, the only real difference is I modified the routing code so that when it receives a RTM_GET request from a jailed process, it re-defines the source address of the route so that it corresponds with the prisons IP. I have tested these patches and they appear to work, however I ask for people to test and scrutinize these patches. Feedback/comments are welcome. Regards Christian S.J. Peron --------> new and improved patch <----------- --- sys/kern/kern_jail.c.bak Mon Apr 19 16:55:40 2004 +++ sys/kern/kern_jail.c Mon Apr 19 17:56:03 2004 @@ -53,6 +53,11 @@ &jail_sysvipc_allowed, 0, "Processes in jail can use System V IPC primitives"); +int jail_allow_raw_sockets = 0; +SYSCTL_INT(_security_jail, OID_AUTO, allow_raw_sockets, CTLFLAG_RW, + &jail_allow_raw_sockets, 0, + "Prison root can create raw sockets"); + /* allprison, lastprid, and prisoncount are protected by allprison_mtx. */ struct prisonlist allprison; struct mtx allprison_mtx; --- sys/net/rtsock.c.bak Wed Apr 21 03:09:41 2004 +++ sys/net/rtsock.c Thu Apr 22 17:37:42 2004 @@ -52,6 +52,8 @@ #include #include +#include + MALLOC_DEFINE(M_RTABLE, "routetbl", "routing tables"); /* NB: these are not modified */ @@ -289,6 +291,7 @@ int len, error = 0; struct ifnet *ifp = 0; struct ifaddr *ifa = 0; + struct sockaddr_in jail; #define senderr(e) { error = e; goto flush;} if (m == 0 || ((m->m_len < sizeof(long)) && @@ -400,8 +403,14 @@ ifp = rt->rt_ifp; if (ifp) { info.rti_info[RTAX_IFP] = TAILQ_FIRST(&ifp->if_addrhead)->ifa_addr; - info.rti_info[RTAX_IFA] = - rt->rt_ifa->ifa_addr; + if (so->so_cred->cr_prison) { + jail.sin_family = PF_INET; + jail.sin_len = sizeof(jail); + jail.sin_addr.s_addr = htonl(so->so_cred->cr_prison->pr_ip); + info.rti_info[RTAX_IFA] = (struct sockaddr *)&jail; + } else + info.rti_info[RTAX_IFA] = + rt->rt_ifa->ifa_addr; if (ifp->if_flags & IFF_POINTOPOINT) info.rti_info[RTAX_BRD] = rt->rt_ifa->ifa_dstaddr; --- sys/netinet/raw_ip.c.b Mon Apr 19 16:23:57 2004 +++ sys/netinet/raw_ip.c Thu Apr 22 18:30:42 2004 @@ -40,6 +40,7 @@ #include "opt_random_ip_id.h" #include +#include #include #include #include @@ -215,6 +216,10 @@ if (inp->inp_faddr.s_addr && inp->inp_faddr.s_addr != ip->ip_src.s_addr) goto docontinue; + if (inp->inp_socket->so_cred->cr_prison) + if (htonl(inp->inp_socket->so_cred->cr_prison->pr_ip) + != ip->ip_dst.s_addr) + goto docontinue; if (last) { struct mbuf *n; @@ -270,7 +275,11 @@ ip->ip_off = 0; ip->ip_p = inp->inp_ip_p; ip->ip_len = m->m_pkthdr.len; - ip->ip_src = inp->inp_laddr; + if (inp->inp_socket->so_cred->cr_prison) + ip->ip_src.s_addr = + htonl(inp->inp_socket->so_cred->cr_prison->pr_ip); + else + ip->ip_src = inp->inp_laddr; ip->ip_dst.s_addr = dst; ip->ip_ttl = inp->inp_ip_ttl; } else { @@ -279,6 +288,13 @@ return(EMSGSIZE); } ip = mtod(m, struct ip *); + if (inp->inp_socket->so_cred->cr_prison) { + if (ip->ip_src.s_addr != + htonl(inp->inp_socket->so_cred->cr_prison->pr_ip)) { + m_freem(m); + return (EPERM); + } + } /* don't allow both user specified and setsockopt options, and don't allow packet length sizes that will crash */ if (((ip->ip_hl != (sizeof (*ip) >> 2)) @@ -505,6 +521,7 @@ } } +extern int jail_allow_raw_sockets; u_long rip_sendspace = RIPSNDQ; u_long rip_recvspace = RIPRCVQ; @@ -527,7 +544,11 @@ INP_INFO_WUNLOCK(&ripcbinfo); return EINVAL; } - if (td && (error = suser(td)) != 0) { + if (td && jailed(td->td_ucred) && !jail_allow_raw_sockets) { + INP_INFO_WUNLOCK(&ripcbinfo); + return (EPERM); + } + if (td && (error = suser_cred(td->td_ucred, PRISON_ROOT)) != 0) { INP_INFO_WUNLOCK(&ripcbinfo); return error; } @@ -626,6 +647,15 @@ if (nam->sa_len != sizeof(*addr)) return EINVAL; + + if (td->td_ucred->cr_prison) { + if (addr->sin_addr.s_addr == INADDR_ANY) + addr->sin_addr.s_addr = + htonl(td->td_ucred->cr_prison->pr_ip); + if (htonl(td->td_ucred->cr_prison->pr_ip) + != addr->sin_addr.s_addr) + return (EADDRNOTAVAIL); + } if (TAILQ_EMPTY(&ifnet) || (addr->sin_family != AF_INET && addr->sin_family != AF_IMPLINK) || From owner-freebsd-security@FreeBSD.ORG Thu Apr 22 16:26:17 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD7C716A4CE for ; Thu, 22 Apr 2004 16:26:17 -0700 (PDT) Received: from ibague.terra.com.br (ibague.terra.com.br [200.154.55.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9ADEC43D48 for ; Thu, 22 Apr 2004 16:26:16 -0700 (PDT) (envelope-from suporte@wahtec.com.br) Received: from potosi.terra.com.br (potosi.terra.com.br [200.154.55.131]) by ibague.terra.com.br (Postfix) with ESMTP id 2EA0DECB93 for ; Thu, 22 Apr 2004 20:26:15 -0300 (BRT) Received: from wahottisray (unknown [200.96.65.150]) (authenticated user arisjr) by potosi.terra.com.br (Postfix) with ESMTP id 8FE63370022 for ; Thu, 22 Apr 2004 20:26:14 -0300 (BRT) From: "Aristeu Gil Alves Jr" To: "Freebsd-Security" Date: Fri, 23 Apr 2004 20:26:53 -0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Subject: ipfilter/ipfw + bridge + out checking X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 23:26:18 -0000 Hi all. I didn't find any thread discussing it, sorry if I am re-posting the same subject. Is there a way to check the ipfilter/ipfw out-flow with bridge? Is it implemented? I've heard its not done due a performance issue (it's writen in ipf-howto), but performance is not the main goal for me in this single situation. I would like to have the stateful firewall and the bridge _fully_ working together. Best regards, --aristeu From owner-freebsd-security@FreeBSD.ORG Thu Apr 22 21:09:52 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E32016A4CE for ; Thu, 22 Apr 2004 21:09:52 -0700 (PDT) Received: from bast.unixathome.org (bast.unixathome.org [66.11.174.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A93D43D31 for ; Thu, 22 Apr 2004 21:09:52 -0700 (PDT) (envelope-from dan@langille.org) Received: from wocker (wocker.unixathome.org [192.168.0.99]) by bast.unixathome.org (Postfix) with ESMTP id 1854E3D31 for ; Fri, 23 Apr 2004 00:09:51 -0400 (EDT) From: "Dan Langille" To: freebsd-security@FreeBSD.org Date: Fri, 23 Apr 2004 00:09:51 -0400 MIME-Version: 1.0 Message-ID: <40885ECF.22456.1C68F42E@localhost> Priority: normal X-mailer: Pegasus Mail for Windows (v4.02a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Subject: IPsec - got ESP going, but not AH X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2004 04:09:52 -0000 Hi folks, I've been working on getting my WiFi network running with IPsec. I'm at the point where all traffic on the wifi subnet is encrypted (i.e. ESP). Then I tried to add AH to the equation. I failed. This picture describes the network setup: http://beta.freebsddiary.org/images/ipsec-wireless.gif Here's what I'm trying and failing with. With these rules, I get no comms between the laptop and the gateway. If I remove the "ah/tunnel/..." clauses from the sdpadd statements, everything moves along nicely. What am I missing here? Any ideas? Thank you. rules for the laptop (encrypting + authentication) add 10.0.0.1 10.0.0.10 esp 691 -E rijndael-cbc "1234567890123456"; add 10.0.0.10 10.0.0.1 esp 693 -E rijndael-cbc "1234567890123456"; add 10.0.0.1 10.0.0.10 ah 15700 -A hmac-md5 "1234567890123456"; add 10.0.0.10 10.0.0.1 ah 24500 -A hmac-md5 "1234567890123456"; spdadd 10.0.0.0/24 0.0.0.0/0 any -P out ipsec esp/tunnel/10.0.0.10-10.0.0.1/require ah/tunnel/10.0.0.10-10.0.0.1/require; spdadd 0.0.0.0/0 10.0.0.0/24 any -P in ipsec esp/tunnel/10.0.0.1-10.0.0.10/require ah/tunnel/10.0.0.1-10.0.0.10/require; rules for the gateway (encrypting + authentication) add 10.0.0.1 10.0.0.10 esp 691 -E rijndael-cbc "1234567890123456"; add 10.0.0.10 10.0.0.1 esp 693 -E rijndael-cbc "1234567890123456"; add 10.0.0.1 10.0.0.10 ah 15700 -A hmac-md5 "1234567890123456"; add 10.0.0.10 10.0.0.1 ah 24500 -A hmac-md5 "1234567890123456"; spdadd 10.0.0.0/24 0.0.0.0/0 any -P in ipsec esp/tunnel/10.0.0.10-10.0.0.1/require ah/tunnel/10.0.0.10-10.0.0.1/require; spdadd 0.0.0.0/0 10.0.0.0/24 any -P out ipsec esp/tunnel/10.0.0.1-10.0.0.10/require ah/tunnel/10.0.0.1-10.0.0.10/require; -- Dan Langille : http://www.langille.org/ BSDCan - http://www.bsdcan.org/ From owner-freebsd-security@FreeBSD.ORG Fri Apr 23 01:57:15 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5ABFB16A4CE for ; Fri, 23 Apr 2004 01:57:15 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 722AA43D48 for ; Fri, 23 Apr 2004 01:57:14 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 40647 invoked from network); 23 Apr 2004 08:57:13 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 23 Apr 2004 08:57:13 -0000 X-pair-Authenticated: 209.68.2.70 Date: Fri, 23 Apr 2004 04:04:10 -0500 (CDT) From: Mike Silbersack To: jayanth In-Reply-To: <20040422145857.GA75539@yahoo-inc.com> Message-ID: <20040423040235.R703@odysseus.silby.com> References: <20040421184539.H18583@odysseus.silby.com> <20040422145857.GA75539@yahoo-inc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-security@FreeBSD.org cc: Don Lewis cc: avalon@caligula.anu.edu.au Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2004 08:57:15 -0000 On Thu, 22 Apr 2004, jayanth wrote: > if i remember right this was done to handle the Alteons which > generate a RST segment that would fall within the window size but not the > next expected sequence no. > So they would do something crazy like rcv_nxt + rcv_win as the sequence no, > for the RST segment rather than rcv_nxt + 1. > This was part of the RFC though. > > If it is a problem we can always revert it back. > > jayanth What type of packet was causing the Alteons to emit the RST? SYN, FIN, normal data? Also, has Alteon fixed the problem or do their load balancers still exhibit the behavior? Mike "Silby" Silbersack From owner-freebsd-security@FreeBSD.ORG Thu Apr 22 07:59:23 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0EA616A4CE; Thu, 22 Apr 2004 07:59:23 -0700 (PDT) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id C195C43D1F; Thu, 22 Apr 2004 07:59:23 -0700 (PDT) (envelope-from jayanth@yahoo-inc.com) Received: from milk.yahoo.com (milk.yahoo.com [216.145.52.137]) i3MEwv8Q069347; Thu, 22 Apr 2004 07:58:57 -0700 (PDT) Received: (from root@localhost) by milk.yahoo.com (8.12.9/8.12.9) id i3MEwvM1075896; Thu, 22 Apr 2004 07:58:57 -0700 (PDT) (envelope-from jayanth) Date: Thu, 22 Apr 2004 07:58:57 -0700 From: jayanth To: Don Lewis Message-ID: <20040422145857.GA75539@yahoo-inc.com> References: <20040421184539.H18583@odysseus.silby.com> <200404212331.i3LNVE7E047907@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200404212331.i3LNVE7E047907@gw.catspoiler.org> User-Agent: Mutt/1.4.1i X-Mailman-Approved-At: Fri, 23 Apr 2004 02:29:10 -0700 cc: freebsd-security@FreeBSD.org cc: avalon@caligula.anu.edu.au cc: jayanth@yahoo-inc.com Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2004 14:59:24 -0000 Don Lewis (truckman@FreeBSD.org) wrote: > On 21 Apr, Mike Silbersack wrote: > > > > On Wed, 21 Apr 2004, Don Lewis wrote: > > > >> > 1. Accept all RSTs meeting the criteria you just listed above. > >> > >> At this step, it would be better if we used the window size that was > >> advertised it the last packet sent, since that is what the sequence > >> number of the RST packet will be calculated from, while the window size > >> could have increased if data was consumed from the receive queue between > >> the time we sent the last packet and when we received the RST. > >> > >> It doesn't look like we keep the necessary data for this. Probably the > >> easiest thing to do would be to calculate the expected sequence number > >> in tcp_output() and stash it in the pcb. > > > > Do you have access to a system that exhibits the "RST at end of window" > > syndrome so that you could code up and test out this part of the patch? > > Nope. The only report of this that I saw was from jayanth. Judging by > the tcpdump timestamps, it looks like whatever this wierd piece of > hardware was, it was nearby. > if i remember right this was done to handle the Alteons which generate a RST segment that would fall within the window size but not the next expected sequence no. So they would do something crazy like rcv_nxt + rcv_win as the sequence no, for the RST segment rather than rcv_nxt + 1. This was part of the RFC though. If it is a problem we can always revert it back. jayanth From owner-freebsd-security@FreeBSD.ORG Fri Apr 23 03:41:47 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65FA116A4CE for ; Fri, 23 Apr 2004 03:41:47 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2333143D46 for ; Fri, 23 Apr 2004 03:41:47 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i3NAfR7E051507; Fri, 23 Apr 2004 03:41:31 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200404231041.i3NAfR7E051507@gw.catspoiler.org> Date: Fri, 23 Apr 2004 03:41:27 -0700 (PDT) From: Don Lewis To: silby@silby.com In-Reply-To: <20040423040235.R703@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-security@FreeBSD.org cc: avalon@caligula.anu.edu.au cc: jayanth@yahoo-inc.com Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2004 10:41:47 -0000 On 23 Apr, Mike Silbersack wrote: > > On Thu, 22 Apr 2004, jayanth wrote: > >> if i remember right this was done to handle the Alteons which >> generate a RST segment that would fall within the window size but not the >> next expected sequence no. >> So they would do something crazy like rcv_nxt + rcv_win as the sequence no, >> for the RST segment rather than rcv_nxt + 1. >> This was part of the RFC though. >> >> If it is a problem we can always revert it back. >> >> jayanth > > What type of packet was causing the Alteons to emit the RST? SYN, FIN, > normal data? > > Also, has Alteon fixed the problem or do their load balancers still > exhibit the behavior? The link I posted showed it was a FIN, and after the RST was sent (and ignored by the FreeBSD stack because of the strict sequence number check), the Alteon (or whatever it was) did not respond to the retransmissions of the FIN packet. Maybe we can get by with the strict check by default and add a sysctl to revert to the permissive check. From owner-freebsd-security@FreeBSD.ORG Fri Apr 23 05:02:17 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BA1816A4CE for ; Fri, 23 Apr 2004 05:02:17 -0700 (PDT) Received: from fnord.ir.bbn.com (fnord.ir.bbn.com [192.1.100.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1C9743D1F for ; Fri, 23 Apr 2004 05:02:16 -0700 (PDT) (envelope-from gdt@ir.bbn.com) Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id E5FE61F69; Fri, 23 Apr 2004 08:02:15 -0400 (EDT) To: "Dan Langille" References: <40885ECF.22456.1C68F42E@localhost> From: Greg Troxel Date: 23 Apr 2004 08:02:15 -0400 In-Reply-To: <40885ECF.22456.1C68F42E@localhost> Message-ID: Lines: 12 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-security@FreeBSD.org Subject: Re: IPsec - got ESP going, but not AH X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2004 12:02:17 -0000 While this should probably work, it's more straightforward to use ESP with integrity protection. That is, use a -A hmac-sha1 argument also to ESP. (hmac-md5 is probably still fine, but sha1 goes better strength-wise with rijndael-cbc.) I believe that in tunnel mode AH and ESP integrity are essentially identical - but read RFC2401 and rfc2401bis (i-d from ipsec wg) if you really want to understand. In transport mode, AH protects parts of the original (and only) IP header. -- Greg Troxel From owner-freebsd-security@FreeBSD.ORG Fri Apr 23 07:27:52 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDF2116A4CE for ; Fri, 23 Apr 2004 07:27:52 -0700 (PDT) Received: from ux1.ibb.net (ux1.ibb.net [64.215.98.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC41043D1F for ; Fri, 23 Apr 2004 07:27:51 -0700 (PDT) (envelope-from mipam@ibb.net) Received: from localhost (mipam@localhost) by ux1.ibb.net (8.9.3/8.9.3/UX1TT) with ESMTP id PAA01805 for ; Fri, 23 Apr 2004 15:17:32 +0200 X-Authentication-Warning: ux1.ibb.net: mipam owned process doing -bs Date: Fri, 23 Apr 2004 15:17:32 +0200 (MET DST) From: Mipam To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: use keep state(strict) to mitigate tcp issues? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2004 14:27:53 -0000 Hi, When deploying a BSD with IPF in at the network perimeter and using rules like these: pass in .. proto tcp ... keep state(strict) it's possible to refuse tcp packets which arrive out of order. This would increase the difficulty doing blind attack resets and blind data injection attack, cause then you'd have to "guess" the exact expected number. Checpoint has a similar feature (is that right?) which is described here as the answer to the mentioned attacks: http://www.checkpoint.com/techsupport/alerts/tcp_dos.html Allthough this is nice, there is also the risk of breaking connection because it's not unlikely that packets arrive out of order. At least, that's what i think, any thoughts upon this? Bye, Mipam. From owner-freebsd-security@FreeBSD.ORG Fri Apr 23 07:39:49 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC0C516A4CE for ; Fri, 23 Apr 2004 07:39:49 -0700 (PDT) Received: from bast.unixathome.org (bast.unixathome.org [66.11.174.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEC7243D1F for ; Fri, 23 Apr 2004 07:39:49 -0700 (PDT) (envelope-from dan@langille.org) Received: from wocker (wocker.unixathome.org [192.168.0.99]) by bast.unixathome.org (Postfix) with ESMTP id ECA7A3D32; Fri, 23 Apr 2004 10:39:48 -0400 (EDT) From: "Dan Langille" To: Greg Troxel Date: Fri, 23 Apr 2004 10:39:49 -0400 MIME-Version: 1.0 Message-ID: <4088F275.17020.1EA9BE84@localhost> Priority: normal References: <40885ECF.22456.1C68F42E@localhost> In-reply-to: X-mailer: Pegasus Mail for Windows (v4.02a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body cc: freebsd-security@FreeBSD.org Subject: Re: IPsec - got ESP going, but not AH X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2004 14:39:50 -0000 On 23 Apr 2004 at 8:02, Greg Troxel wrote: > While this should probably work, it's more straightforward to use ESP > with integrity protection. That is, use a -A hmac-sha1 argument also > to ESP. (hmac-md5 is probably still fine, but sha1 goes better > strength-wise with rijndael-cbc.) Thank you for your suggestions. Based on that, I've tried the following, which works for me: add 10.0.0.1 10.0.0.10 esp 691 -E rijndael-cbc "1234567890123456" -A hmac-sha1 "12345678901234567890"; add 10.0.0.10 10.0.0.1 esp 693 -E rijndael-cbc "1234567890123456" -A hmac-sha1 "12345678901234567890"; spdadd 10.0.0.0/24 0.0.0.0/0 any -P out ipsec esp/tunnel/10.0.0.10- 10.0.0.1/require; spdadd 0.0.0.0/0 10.0.0.0/24 any -P in ipsec esp/tunnel/10.0.0.1- 10.0.0.10/require; Cheers -- Dan Langille : http://www.langille.org/ BSDCan - http://www.bsdcan.org/ From owner-freebsd-security@FreeBSD.ORG Fri Apr 23 07:44:28 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E01A016A4CE for ; Fri, 23 Apr 2004 07:44:28 -0700 (PDT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 4D7FD43D5A for ; Fri, 23 Apr 2004 07:44:27 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 7928 invoked from network); 23 Apr 2004 14:37:52 -0000 Received: from office.sbnd.net (HELO straylight.m.ringlet.net) (217.75.140.130) by gandalf.online.bg with SMTP; 23 Apr 2004 14:37:52 -0000 Received: (qmail 63536 invoked by uid 1000); 23 Apr 2004 14:44:22 -0000 Date: Fri, 23 Apr 2004 17:44:22 +0300 From: Peter Pentchev To: Mipam Message-ID: <20040423144422.GD961@straylight.m.ringlet.net> Mail-Followup-To: Mipam , freebsd-security@freebsd.org References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EuxKj2iCbKjpUGkD" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: freebsd-security@freebsd.org Subject: Re: use keep state(strict) to mitigate tcp issues? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2004 14:44:29 -0000 --EuxKj2iCbKjpUGkD Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 23, 2004 at 03:17:32PM +0200, Mipam wrote: > Hi, >=20 > When deploying a BSD with IPF in at the network perimeter > and using rules like these: >=20 > pass in .. proto tcp ... keep state(strict) >=20 > it's possible to refuse tcp packets which arrive out of order. > This would increase the difficulty doing blind attack resets and blind > data injection attack, cause then you'd have to "guess" the exact expected > number. Checpoint has a similar feature (is that right?) which is > described here as the answer to the mentioned attacks: >=20 > http://www.checkpoint.com/techsupport/alerts/tcp_dos.html >=20 > Allthough this is nice, there is also the risk of breaking > connection because it's not unlikely that packets arrive out of order. > At least, that's what i think, any thoughts upon this? IMHO, in the world of multihomed ISP's, BGP and multipath routing, no, it is definitely *not* unlikely that packets should arrive out of order. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@sbnd.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If I were you, who would be reading this sentence? --EuxKj2iCbKjpUGkD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFAiSvG7Ri2jRYZRVMRAr3EAKCY5SzMGjTs0X9SmClNAJctFUG78wCfQImk EBpeR056NKhtVWjG+CE5KaY= =S8zF -----END PGP SIGNATURE----- --EuxKj2iCbKjpUGkD-- From owner-freebsd-security@FreeBSD.ORG Fri Apr 23 08:31:23 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42D3E16A4CF for ; Fri, 23 Apr 2004 08:31:23 -0700 (PDT) Received: from caligula.anu.edu.au (caligula.anu.edu.au [150.203.224.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id A759D43D5E for ; Fri, 23 Apr 2004 08:31:22 -0700 (PDT) (envelope-from avalon@caligula.anu.edu.au) Received: from caligula.anu.edu.au (localhost [127.0.0.1]) by caligula.anu.edu.au (8.12.9/8.12.9) with ESMTP id i3NFVKbF026625; Sat, 24 Apr 2004 01:31:21 +1000 (EST) Received: (from avalon@localhost) by caligula.anu.edu.au (8.12.9/8.12.8/Submit) id i3NFVK9m026622; Sat, 24 Apr 2004 01:31:20 +1000 (EST) From: Darren Reed Message-Id: <200404231531.i3NFVK9m026622@caligula.anu.edu.au> To: mipam@ibb.net (Mipam) Date: Sat, 24 Apr 2004 01:31:20 +1000 (Australia/ACT) In-Reply-To: from "Mipam" at Apr 23, 2004 03:17:32 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-security@freebsd.org Subject: Re: use keep state(strict) to mitigate tcp issues? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2004 15:31:23 -0000 In some mail from Mipam, sie said: > > Hi, > > When deploying a BSD with IPF in at the network perimeter > and using rules like these: > > pass in .. proto tcp ... keep state(strict) > > it's possible to refuse tcp packets which arrive out of order. > This would increase the difficulty doing blind attack resets and blind > data injection attack, cause then you'd have to "guess" the exact expected > number. Checpoint has a similar feature (is that right?) which is > described here as the answer to the mentioned attacks: > > http://www.checkpoint.com/techsupport/alerts/tcp_dos.html > > Allthough this is nice, there is also the risk of breaking > connection because it's not unlikely that packets arrive out of order. > At least, that's what i think, any thoughts upon this? My thoughts are that if the TCP on both ends is having trouble, it will eventually fall back and get packets through that match the state entries for "strict". I would not, for example, advise using "strict" for state connections where you intend on sending 100s of megabytes over fast networks,. In IPFilter, the "strict" applies to all TCP packets for a connection, not just the SYNs or RSTs. Darren From owner-freebsd-security@FreeBSD.ORG Fri Apr 23 16:10:02 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 614D616A4CE for ; Fri, 23 Apr 2004 16:10:02 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id CCFC543D1D for ; Fri, 23 Apr 2004 16:10:01 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 58921 invoked from network); 23 Apr 2004 23:10:00 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 23 Apr 2004 23:10:00 -0000 X-pair-Authenticated: 209.68.2.70 Date: Fri, 23 Apr 2004 18:32:06 -0500 (CDT) From: Mike Silbersack To: Don Lewis In-Reply-To: <200404231041.i3NAfR7E051507@gw.catspoiler.org> Message-ID: <20040423182801.G5436@odysseus.silby.com> References: <200404231041.i3NAfR7E051507@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-security@FreeBSD.org cc: avalon@caligula.anu.edu.au cc: jayanth@yahoo-inc.com Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2004 23:10:02 -0000 On Fri, 23 Apr 2004, Don Lewis wrote: > > What type of packet was causing the Alteons to emit the RST? SYN, FIN, > > normal data? > > > > Also, has Alteon fixed the problem or do their load balancers still > > exhibit the behavior? > > The link I posted showed it was a FIN, and after the RST was sent (and > ignored by the FreeBSD stack because of the strict sequence number > check), the Alteon (or whatever it was) did not respond to the > retransmissions of the FIN packet. > > Maybe we can get by with the strict check by default and add a sysctl to > revert to the permissive check. I think Darren's suggestion would be a reasonable compromise; use the strict check in the ESTABLISHED state, and the permissive check otherwise. Established connections are what would be attacked, so we need the security there, but the closing states are where oddities seem to pop up, so we can use the permissive check there. If this is acceptable, I'd like to get it committed this weekend so that we can still get it into 4.10. Mike "Silby" Silbersack From owner-freebsd-security@FreeBSD.ORG Fri Apr 23 16:34:48 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A635C16A4CE for ; Fri, 23 Apr 2004 16:34:48 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 33D7643D54 for ; Fri, 23 Apr 2004 16:34:48 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 68179 invoked from network); 23 Apr 2004 23:34:47 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 23 Apr 2004 23:34:47 -0000 X-pair-Authenticated: 209.68.2.70 Date: Fri, 23 Apr 2004 18:57:20 -0500 (CDT) From: Mike Silbersack To: jayanth In-Reply-To: <20040423231936.GC21555@yahoo-inc.com> Message-ID: <20040423185501.S5540@odysseus.silby.com> References: <200404231041.i3NAfR7E051507@gw.catspoiler.org> <20040423231936.GC21555@yahoo-inc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-security@FreeBSD.org cc: Don Lewis cc: avalon@caligula.anu.edu.au cc: kernel@yahoo-inc.com Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2004 23:34:48 -0000 On Fri, 23 Apr 2004, jayanth wrote: > > I think Darren's suggestion would be a reasonable compromise; use the > > strict check in the ESTABLISHED state, and the permissive check otherwise. > > Established connections are what would be attacked, so we need the > > security there, but the closing states are where oddities seem to pop up, > > so we can use the permissive check there. > > > > If this is acceptable, I'd like to get it committed this weekend so that > > we can still get it into 4.10. > > > > sure, that sounds reasonable. The sysctl should be good for yahoo. > > thanks, > jayanth There wouldn't be a sysctl, as you wouldn't need one, if I understand things correctly. Since the "bad" RST is in response to the FreeBSD box sending a FIN, the FreeBSD box would have already transitioned to FIN_WAIT_1, and would accept the "bad" RST, as it would only be subject to the check we're using at present. Mike "Silby" Silbersack From owner-freebsd-security@FreeBSD.ORG Fri Apr 23 18:11:04 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3792316A4CE for ; Fri, 23 Apr 2004 18:11:04 -0700 (PDT) Received: from out012.verizon.net (out012pub.verizon.net [206.46.170.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB67243D53 for ; Fri, 23 Apr 2004 18:11:03 -0700 (PDT) (envelope-from cswiger@mac.com) Received: from mac.com ([68.160.247.127]) by out012.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040424011103.QIPB18295.out012.verizon.net@mac.com>; Fri, 23 Apr 2004 20:11:03 -0500 Message-ID: <4089BE9E.8080901@mac.com> Date: Fri, 23 Apr 2004 21:10:54 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Darren Reed References: <200404220829.i3M8TpcB022690@caligula.anu.edu.au> In-Reply-To: <200404220829.i3M8TpcB022690@caligula.anu.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out012.verizon.net from [68.160.247.127] at Fri, 23 Apr 2004 20:11:02 -0500 cc: freebsd-security@freebsd.org Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2004 01:11:04 -0000 Darren Reed wrote: > In some mail from Mike Silbersack, sie said: [ ... ] >> Are you suggesting that we use the strict check during the ESTABLISHED >> phase, and the window-wide check during all other phases? > > Possibly :) > > I don't think it is important for session setup, but at the end of a > session, you generally want it to disappear from your connection table > sooner rather than later, right ? My take on this is that connection setup and teardown phases are generally present (and thus vulnerable to attack) for a very short time interval compared with the time ESTABLISHED connections may persist, so using a strict check for that phase makes sense. > Furthermore, you're more likely to get a RST after a FIN has been > sent, by either party, if you send another ACK because the other > guy has decided to remove the socket already. Does this make > sense ? Yes. > Although this makes me wonder, what's the implication here for FIN > packets - is there none ? The draft refers to SYNs (which do get > special treatment) and RSTs (just more violent FIN packets.) It's not clear to me that under the circumstances required for this attack, there is much difference between injecting a RST or a FIN, or anything else, for that matter: if you know or guess IP addresses, ports, and guess a sequence # in the window, you can inject a packet of data, too. That's enough to mangle any application-layer checksumming.... > If someone injects a FIN packet the way they would have done a RST, > what are the implications ? A FIN seems likely to be dropped as duplicate data: Segments are processed in sequence. Initial tests on arrival are used to discard old duplicates, but further processing is done in SEG.SEQ order. If a segment's contents straddle the boundary between old and new, only the new parts should be processed. A packet containing a FIN is unlikely to match the seq # exactly, and thus is likely to be overwritten by authentic packets, particularly a bare FIN. If you send a lot of data in the packet, perhaps it's more likely that your packet has some data that's accepted and thus the FIN gets processed, but big packets take longer for the attacker to send to send. -- -Chuck From owner-freebsd-security@FreeBSD.ORG Fri Apr 23 20:31:29 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DEF316A4CF for ; Fri, 23 Apr 2004 20:31:29 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 9C2D043D1F for ; Fri, 23 Apr 2004 20:31:28 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 46667 invoked from network); 24 Apr 2004 03:31:26 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 24 Apr 2004 03:31:26 -0000 X-pair-Authenticated: 209.68.2.70 Date: Fri, 23 Apr 2004 22:34:51 -0500 (CDT) From: Mike Silbersack To: freebsd-security@freebsd.org Message-ID: <20040423222922.F1915@odysseus.silby.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-961716412-1082777691=:1915" Subject: Proposed RST patch X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2004 03:31:29 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-961716412-1082777691=:1915 Content-Type: TEXT/PLAIN; charset=US-ASCII Here's my proposed patch to change RST handling so that ESTABLISHED connections are subject to strict RST checking, but connections in other states are only subject to the "within the window" check. Part 2 of the patch is simply a patch to netstat so that it displays the statistic. As expected, it's very straightforward, the only real question is what to call the statistic... "Ignored RSTs in the window" isn't the best description. FWIW, I've been testing with the exploit code (reset-tcp-rfc31337-compliant.c from osvdb-4030-exploit.zip), and this change does indeed defeat the attack. It took me a while to get the code working, they really munged up the libnet calls, but I guess that was the intent. Mike "Silby" Silbersack --0-961716412-1082777691=:1915 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="bad_reset.patch" Content-Transfer-Encoding: BASE64 Content-ID: <20040423223451.T1915@odysseus.silby.com> Content-Description: Content-Disposition: attachment; filename="bad_reset.patch" ZGlmZiAtdSAtciAvdXNyL3NyYy9zeXMub2xkL25ldGluZXQvdGNwX2lucHV0 LmMgL3Vzci9zcmMvc3lzL25ldGluZXQvdGNwX2lucHV0LmMNCi0tLSAvdXNy L3NyYy9zeXMub2xkL25ldGluZXQvdGNwX2lucHV0LmMJVGh1IEFwciAyMiAw MToxNToxNSAyMDA0DQorKysgL3Vzci9zcmMvc3lzL25ldGluZXQvdGNwX2lu cHV0LmMJRnJpIEFwciAyMyAyMjoxMzoxOCAyMDA0DQpAQCAtMTU3MCw2ICsx NTcwLDEwIEBADQogCQkJCWdvdG8gY2xvc2U7DQogDQogCQkJY2FzZSBUQ1BT X0VTVEFCTElTSEVEOg0KKwkJCQlpZiAodHAtPmxhc3RfYWNrX3NlbnQgIT0g dGgtPnRoX3NlcSkgew0KKwkJCQkJdGNwc3RhdC50Y3BzX2JhZHJzdCsrOw0K KwkJCQkJZ290byBkcm9wOw0KKwkJCQl9DQogCQkJY2FzZSBUQ1BTX0ZJTl9X QUlUXzE6DQogCQkJY2FzZSBUQ1BTX0ZJTl9XQUlUXzI6DQogCQkJY2FzZSBU Q1BTX0NMT1NFX1dBSVQ6DQpkaWZmIC11IC1yIC91c3Ivc3JjL3N5cy5vbGQv bmV0aW5ldC90Y3BfdmFyLmggL3Vzci9zcmMvc3lzL25ldGluZXQvdGNwX3Zh ci5oDQotLS0gL3Vzci9zcmMvc3lzLm9sZC9uZXRpbmV0L3RjcF92YXIuaAlU aHUgQXByIDIyIDAxOjE1OjE2IDIwMDQNCisrKyAvdXNyL3NyYy9zeXMvbmV0 aW5ldC90Y3BfdmFyLmgJRnJpIEFwciAyMyAyMjoxMjo0OSAyMDA0DQpAQCAt NDE0LDYgKzQxNCw3IEBADQogCXVfbG9uZwl0Y3BzX2JhZHN5bjsJCS8qIGJv Z3VzIFNZTiwgZS5nLiBwcmVtYXR1cmUgQUNLICovDQogCXVfbG9uZwl0Y3Bz X210dXJlc2VudDsJCS8qIHJlc2VuZHMgZHVlIHRvIE1UVSBkaXNjb3Zlcnkg Ki8NCiAJdV9sb25nCXRjcHNfbGlzdGVuZHJvcDsJLyogbGlzdGVuIHF1ZXVl IG92ZXJmbG93cyAqLw0KKwl1X2xvbmcJdGNwc19iYWRyc3Q7CQkvKiBpZ25v cmVkIFJTVHMgaW4gdGhlIHdpbmRvdyAqLw0KIA0KIAl1X2xvbmcJdGNwc19z Y19hZGRlZDsJCS8qIGVudHJ5IGFkZGVkIHRvIHN5bmNhY2hlICovDQogCXVf bG9uZwl0Y3BzX3NjX3JldHJhbnNtaXR0ZWQ7CS8qIHN5bmNhY2hlIGVudHJ5 IHdhcyByZXRyYW5zbWl0dGVkICovDQo= --0-961716412-1082777691=:1915 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="bad_reset-part2.patch" Content-Transfer-Encoding: BASE64 Content-ID: <20040423223451.F1915@odysseus.silby.com> Content-Description: Content-Disposition: attachment; filename="bad_reset-part2.patch" LS0tIC91c3Ivc3JjL3Vzci5iaW4vbmV0c3RhdC9pbmV0LmMub2xkCUZyaSBB cHIgMjMgMjI6MTk6NDMgMjAwNA0KKysrIC91c3Ivc3JjL3Vzci5iaW4vbmV0 c3RhdC9pbmV0LmMJRnJpIEFwciAyMyAyMjoyMTowOSAyMDA0DQpAQCAtNDE1 LDYgKzQxNSw3IEBADQogCXAodGNwc19hY2NlcHRzLCAiXHQlbHUgY29ubmVj dGlvbiBhY2NlcHQlc1xuIik7DQogCXAodGNwc19iYWRzeW4sICJcdCVsdSBi YWQgY29ubmVjdGlvbiBhdHRlbXB0JXNcbiIpOw0KIAlwKHRjcHNfbGlzdGVu ZHJvcCwgIlx0JWx1IGxpc3RlbiBxdWV1ZSBvdmVyZmxvdyVzXG4iKTsNCisJ cCh0Y3BzX2JhZHJzdCwgIlx0JWx1IElnbm9yZWQgUlNUcyBpbiB0aGUgd2lu ZG93JXNcbiIpOw0KIAlwKHRjcHNfY29ubmVjdHMsICJcdCVsdSBjb25uZWN0 aW9uJXMgZXN0YWJsaXNoZWQgKGluY2x1ZGluZyBhY2NlcHRzKVxuIik7DQog CXAyKHRjcHNfY2xvc2VkLCB0Y3BzX2Ryb3BzLA0KIAkJIlx0JWx1IGNvbm5l Y3Rpb24lcyBjbG9zZWQgKGluY2x1ZGluZyAlbHUgZHJvcCVzKVxuIik7DQo= --0-961716412-1082777691=:1915-- From owner-freebsd-security@FreeBSD.ORG Fri Apr 23 22:00:15 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD02516A4CE for ; Fri, 23 Apr 2004 22:00:15 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 685D843D3F for ; Fri, 23 Apr 2004 22:00:13 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i3O5057E053032; Fri, 23 Apr 2004 22:00:10 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200404240500.i3O5057E053032@gw.catspoiler.org> Date: Fri, 23 Apr 2004 22:00:05 -0700 (PDT) From: Don Lewis To: silby@silby.com In-Reply-To: <20040423222922.F1915@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-security@FreeBSD.org Subject: Re: Proposed RST patch X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2004 05:00:15 -0000 On 23 Apr, Mike Silbersack wrote: > > Here's my proposed patch to change RST handling so that ESTABLISHED > connections are subject to strict RST checking, but connections in other > states are only subject to the "within the window" check. Part 2 of the > patch is simply a patch to netstat so that it displays the statistic. > > As expected, it's very straightforward, the only real question is what to > call the statistic... "Ignored RSTs in the window" isn't the best > description. > > FWIW, I've been testing with the exploit code > (reset-tcp-rfc31337-compliant.c from osvdb-4030-exploit.zip), and this > change does indeed defeat the attack. It took me a while to get the code > working, they really munged up the libnet calls, but I guess that was the > intent. > + if (tp->last_ack_sent != th->th_seq) { I'd reverse the operand order here to match the operand order of the enclosing "if" block. Other than that tiny nit, this looks fine. What is our status with regards to the spoofed SYN version of the attack? From owner-freebsd-security@FreeBSD.ORG Fri Apr 23 23:15:06 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78C8516A4CF for ; Fri, 23 Apr 2004 23:15:06 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id E141F43D3F for ; Fri, 23 Apr 2004 23:15:05 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 2687 invoked from network); 24 Apr 2004 06:15:04 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 24 Apr 2004 06:15:04 -0000 X-pair-Authenticated: 209.68.2.70 Date: Sat, 24 Apr 2004 01:22:04 -0500 (CDT) From: Mike Silbersack To: Don Lewis In-Reply-To: <200404240500.i3O5057E053032@gw.catspoiler.org> Message-ID: <20040424011603.F1915@odysseus.silby.com> References: <200404240500.i3O5057E053032@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-security@FreeBSD.org Subject: Re: Proposed RST patch X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2004 06:15:06 -0000 On Fri, 23 Apr 2004, Don Lewis wrote: > > + if (tp->last_ack_sent != th->th_seq) { > > I'd reverse the operand order here to match the operand order of the > enclosing "if" block. Other than that tiny nit, this looks fine. Ok, I can do that. I also plan to update the comments above. > What is our status with regards to the spoofed SYN version of the > attack? I haven't checked yet. I just finished up modifying the exploit so that it uses icmp unreachables rather than TCP RSTs. In addition to being a good less in libnet, it helped prove that FreeBSD is already good wrt unreach packets (due to work by jlemon and jayanth, IIRC), although I did not test any other operating systems... (Perhaps the draft should have mentioned icmp unreach packets given that they may be handled similarly to RSTs.) SYNs are next on the list. Mike "Silby" Silbersack