On Thu, 20 Jan 2000, Brett Glass wrote:
> >I've been informed today by an irc admin that a new exploit is circulating
> >around. It "sends tcp-established bitstream shit" and makes the "kernel
> >fuck up".
> >
> >It's called stream.c.
>
> Actually, this affects most TCP stacks, including those in Linux, Solaris,
> and all of the BSDs. Not tested under NT or Windows, but I'll bet it does so
> there as well. The problem seems to stem from a worst-case path through the
> kernel's socket lookup code, followed by the overhead of generating
> a RST.
My linux box seems like unvulnerable... Port 80 (open). And localhost and
remote restore pinging immediately after breaking stream. With worked
stream remote machine pinging slow. ~80% packets is loss. localhost not
loss packets.
Remote FreeBSD-2.6 not response with worked stream. After breaking stream
response immediately.
Novel Netware 5 over 100Mb/s connection. First connection very slow, but
later ping going very fine with worked stream. Responding time ~0.2-1 ms.
NPI DS-24 Switch over 100 Mb/s connection. VERY SLOW response ~15000-20000
ms, 95% packets loss if streaming non-worked port. If stream flood on
worked port - no response. After exiting stream - no
response. ooops! Phisical port disabled!
UnixWare7 (7.0.1) over 100 Mb/s. Port 80. With worked stream - no
response. After breaking stream - no response. TCP/IP stack down?
Windows'98 over 100 Mb/s. Port 139. Some freez. Pinging slow. ~80% packets
loss. After breakin stream slow restore.
SCO OpenServer5 - remote. Port 80 (closed). Slow response with worked
stream. After breaking stream - all work fine. Port 23 (open). With worked
stream - very slow response. After breaking - fast restore.
Windows NT - remote. Port 80 (open). With worked stream - slow
response. After breakin - fast restore.
Lan Administrator
E-mail: [EMAIL PROTECTED]
Phone: +380 05322 21535
Member of WaZeLin Trio Team
