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-security" 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>