Date: Thu, 20 Jan 2000 23:32:42 -0700 From: Wes Peters <wes@softweyr.com> To: Brett Glass <brett@lariat.org> Cc: Darren Reed <avalon@coombs.anu.edu.au>, Warner Losh <imp@village.org>, jamiE rishaw - master e*tard <jamiE@arpa.com>, Tom <tom@uniserve.com>, Mike Tancsa <mike@sentex.net>, freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, security-officer@FreeBSD.ORG Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Message-ID: <3887FD8A.379E9B91@softweyr.com> References: <4.2.2.20000120174826.01882ad0@localhost> <4.2.2.20000120180821.0188d5c0@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Brett Glass wrote: > > At 06:03 PM 1/20/2000 , Darren Reed wrote: > > >If you're using "flags S keep state" or "flags S/SA keep state", > >then as far as I'm aware, having read the code, you are safe. > > This might be a workaround. What rule(s) would have to follow it > to block the ACK? > > >I'm intrigued to know what the bug is. Reading the code, it is > >hard to see how you could make a box fall over using it, unless > >there were some serious problems in how random TCP ACK's were > >handled. > > 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.). I don't think so. The handling for bare TCP ACKs isn't all that bad, so I'm not seeing the bug. Maybe tomorrow, after I've slept a bit. Tonight it's just escaping me. From the report, it's obviously a resource usage problem, where the ACKs are being queued up or something, but I can't see it tonight. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3887FD8A.379E9B91>