Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 21 Jan 2000 15:41:13 -0600 (CST)
From:      Gene Harris <zeus@tetronsoftware.com>
To:        Brett Glass <brett@lariat.org>
Cc:        freebsd-security@freebsd.org
Subject:   Re: Some observations on stream.c and streamnt.c
Message-ID:  <Pine.BSF.4.10.10001211534020.4003-100000@tetron02.tetronsoftware.com>
In-Reply-To: <4.2.2.20000121141918.01a54ef0@localhost>

next in thread | previous in thread | raw e-mail | index | archive | help

>  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.  ;-)

>  affect the results. Were the machines on a network with
>  a live gateway router? Remember, traffic to, from, and
>  through the router is significant, since one of the
>  effects of the exploit is to cause a storm of packets
>  on the local LAN.

Yes, there is a gateway.  No packet storm was noticed
between any segments.

>  
>  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*

>  >In the case of Windows 95/98, several more complex
>  >interactions occured, and my FreeBSD machine began to post
>  >jess: No more buffer errors.  I tested the Win98/95 machines
>  >against read/writes against the IDE and reads against the 
>  >DVD subsystems and no apparent performance loss was noticed 
>  >when the machines were under attack. (I used the movie "Gone
>  >With the Wind" as a test on the DVD drive.)
>  
>  Again, a bad test -- I/O and CPU intensive, but not network-
>  intensive.
>  
>  The same seems to be true of the Linux and BSD tests you 
>  describe.

Again, there will be better tests, but the attack is
supposed to take a long path thru the kernel.  It ultimately
kills the machine (supposedly) because it overwhelms the
target's ability to process packets.  Further loading of the
CPU only exascerbates the problem.

I firmly disagree with your observation on NT.

Gene



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?Pine.BSF.4.10.10001211534020.4003-100000>