From owner-freebsd-security Thu Jan 20 18:43: 0 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id CDFF814A29 for ; Thu, 20 Jan 2000 18:42:56 -0800 (PST) (envelope-from brett@lariat.org) Received: from workhorse (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id TAA12918; Thu, 20 Jan 2000 19:42:43 -0700 (MST) Message-Id: <4.2.2.20000120194037.0188de10@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 20 Jan 2000 19:42:43 -0700 To: marcs@go2net.com From: Brett Glass Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Cc: freebsd-security@FreeBSD.ORG In-Reply-To: References: <4.2.2.20000120180821.0188d5c0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 06:23 PM 1/20/2000 , marcs@go2net.com wrote: >On Thu, 20 Jan 2000, Brett Glass wrote: > > > My guess is that there's a long code path, or other inefficiency, > > in the way the ACK is handled. Perhaps a linear search for the > > right socket instead of one that's more clevery implemented > > (e.g. search by port, then address, etc.). > >How about you stop making random guess after random guess about what the >fixes are when you don't even know what the problem is, Actually, I do have some idea about what the problem is. I'm hoping that a quick discussion will lead to (a) a fast workaround to protect many servers -- IPFilter rules would be nice because they could be applied to lots of systems -- and (b) a long-term patch for FreeBSD. I've already been analyzing the worst-case code paths in the kernel. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message