Re: Quick remedy for stream.c

[bella () PCI POLTAVA UA (bella)]

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: bella () pci poltava ua
Phone: +380 05322 21535
Member of WaZeLin Trio Team