Date: Fri, 21 Jan 2000 14:53:17 -0700 From: Brett Glass <brett@lariat.org> To: Gene Harris <zeus@tetronsoftware.com> Cc: freebsd-security@freebsd.org Subject: Re: Some observations on stream.c and streamnt.c Message-ID: <4.2.2.20000121144504.01a5a990@localhost> In-Reply-To: <Pine.BSF.4.10.10001211534020.4003-100000@tetron02.tetronso ftware.com> References: <4.2.2.20000121141918.01a54ef0@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
At 02:41 PM 1/21/2000 , Gene Harris wrote: > > A poor test, IMHO. It's disk-intensive and CPU-intensive, > > but not network-intensive. Also, other conditions can > >True, but again, putting together a test on short notice, >one uses the tools at hand. ;-) Yep, I understand this quite well. Darren saw results that seem more typical; you might ask him what his configuration was. >Yes, there is a gateway. No packet storm was noticed >between any segments. The packet storm seems to brew between the victim and its router. The router settings may matter. If multicast addresses are used, I could imagine that other machines on the LAN might get involved, though I have not checked this. > > I've made an NT/IIS server virtually inaccessible using > > the same exploit. > >Hmmm... We need to compare detailed notes, because I saw no >affect what-so-ever. I also have the ability to put the >server on the inet for you to test against, if you would >like. However, I see that we both ran the same "bad" test. >*grin* The difference may be that I was exercising IIS specifically. Exercising the back-end database probably doesn't affect the LAN. >Again, there will be better tests, but the attack is >supposed to take a long path thru the kernel. That's ONE of its problems. Some of the fixes that have been proposed on this list can cut the time to recognize that the packet is bogus by more than half. >It ultimately >kills the machine (supposedly) because it overwhelms the >target's ability to process packets. Not just that. I suspect that it runs out of buffers because it's queueing up RST packets and ICMP packets. And discarding important incoming packets in the process. (Which is another thing you'll see in a test: the more INPUT the server needs to accept, the more it will be affected.) >I firmly disagree with your observation on NT. I'm willing to believe that you saw different results than me in your test setup. But I saw a big impact on mine. --Brett 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?4.2.2.20000121144504.01a5a990>