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: bellaat_private Phone: +380 05322 21535 Member of WaZeLin Trio Team
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:30:37 PDT