From owner-freebsd-security Fri Jan 21 13:15: 7 2000 Delivered-To: freebsd-security@freebsd.org Received: from tetron02.tetronsoftware.com (ftp.tetronsoftware.com [208.236.46.106]) by hub.freebsd.org (Postfix) with ESMTP id 4C8B01553F for ; Fri, 21 Jan 2000 13:15:03 -0800 (PST) (envelope-from zeus@tetronsoftware.com) Received: from tetron02.tetronsoftware.com (tetron02.tetronsoftware.com [208.236.46.106]) by tetron02.tetronsoftware.com (8.9.3/8.9.3) with ESMTP id PAA04126; Fri, 21 Jan 2000 15:18:28 -0600 (CST) (envelope-from zeus@tetronsoftware.com) Date: Fri, 21 Jan 2000 15:18:28 -0600 (CST) From: Gene Harris To: Brett Glass Cc: freebsd-security@freebsd.org Subject: Some observations on stream.c and streamnt.c In-Reply-To: <4.2.2.20000120194543.019a8d50@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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