Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 21 Jan 2000 15:18:28 -0600 (CST)
From:      Gene Harris <zeus@tetronsoftware.com>
To:        Brett Glass <brett@LARIAT.ORG>
Cc:        freebsd-security@freebsd.org
Subject:   Some observations on stream.c and streamnt.c
Message-ID:  <Pine.BSF.4.10.10001211419010.3943-100000@tetron02.tetronsoftware.com>
In-Reply-To: <4.2.2.20000120194543.019a8d50@localhost>

next in thread | previous in thread | raw e-mail | index | archive | help
Mr. Glass,

I have been working with stream.c against five operating
systems on a 100 MBit private network.  Your assumption that
it has a bad effect on NT, or Windows 95/98 is incorrect,
per your posting in bugtrack.

All five machines were equipped with PII 400MHz processors
and 128 MB RAM (except for the NT Server, which has 256MB 
RAM) and Intel EEPro 100 cards. All used IDE disk drives.
All drives are IBM 18G OEM'ed from WD I think.  (There was a
sale, and they were $200 each, so I bough 10 for my
business.)

After eight hours of testing, in which I have been
bombarding the NT 4.0 SP6a Server, the CPU usage on an
unloaded machine jumped to 27%.  However, when I started up
Oracle 8.05 and ran a rather lengthy query against a 400MB
database, no distinguishable differences exist in the query
time between a machine under attack and one not under
attack.

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

These tests were run using the command ./stream 10.0.0.x 137
0 100000.

As for crashing a Linux machine, I attempted the same attack
as above on a machine running Red Hat 6.1 and executing IBM
DB2 queries. I changed the port to 80 because I did have a
web server running.  This machine slowed very considerably
in user response, but did not crash.  After 25 minutes, the
ide subsystem reset itself, and the Redhat machine
complained that the CD-ROM could not be read.  (There was no
CD-ROM in the drive.)  However, DB2 did not crash, and the
cgi scripts continued to execute, feeding data correctly to
the web pages.

The Redhat 6.1 machine returned to normal operation with in
seconds of stopping the attack.  No reboot was required.

I then used the Redhat 6.1 machine to attack the FreeBSD
server, and there was almost no effect.  As per some reports
last night for Solaris, certain network operations were
slower, but otherwise, there was no effect on any executing
server software, including PostgreSQL and a StarOffice
document I was working on.  The top command reported
interrupts of 35.6% on the BDS machine.  I have seen worse
with a busy Samba server.

I hacked the stream.c script (calling it streamnt.c) to
execute from NT and could not produce enough packets to
affect either the FreeBSD or Linux machine.  I am working on
improving the attack, but I do not think the results will be
any different and probably not worth the effort of improving
the attacking program.

In my opinion, the set of circumstances necessary to cause
these DoS attacks to succeed in crashing a server include
very heavy loading, and the design of the software driver
for the NIC.  I also think such attacks might be more
successful against older hardware, such as Pent 200MHz and
earlier and older ISA NIC's, which are limited in the
interrupt handling rate.

I am sending you this email because I think the threat of
stream.c is at best very minimal.  In particular, it does
not appear to me that switching from ipfw to ipfilter is
called for.  I know these tests are not scientific, and are
subject to some changes in observations depending on who
does the measurements.

*==============================================*
*Gene Harris      http://www.tetronsoftware.com*
*FreeBSD Novice                                *
*All ORBS.org SMTP connections are denied!     *
*==============================================*






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.10001211419010.3943-100000>