From owner-freebsd-questions Fri Jan 21 23:39:57 2000 Delivered-To: freebsd-questions@freebsd.org Received: from hsalouserv1.hsacorp.net (208-247-171-50.hsacorp.net [208.247.171.50]) by hub.freebsd.org (Postfix) with ESMTP id E248015432 for ; Fri, 21 Jan 2000 23:39:52 -0800 (PST) (envelope-from jconner@enterit.com) Received: from default (24-216-177-226.hsacorp.net [24.216.177.226]) by hsalouserv1.hsacorp.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id CPRQJ6CG; Sat, 22 Jan 2000 02:33:34 -0500 Message-Id: <4.2.0.58.20000121022751.00d19d20@mail.enterit.com> X-Sender: jconner@mail.enterit.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 21 Jan 2000 02:41:31 -0500 To: FreeBSD Questions From: Jim Conner Subject: stream.c workaround -> IPF /dev/ipl Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG (from bugtraq)...see below -- snip -- At 03:44 PM 1/18/2000 , The Tree of Life 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. A quick bull session on the FreeBSD Security list has produced a workaround that works on all of the BSDs and in fact anything that runs IPFilter. I asked Darren Reed, author of IPFilter (which now comes with all of the BSDs) if it's possible to block the attack using his firewall code, and he says it is. Darren writes that the rules are as follows: >pass in all >block in proto tcp all head 100 >pass in proto tcp from any to any flags S keep state group 100 (Change group 100 to something else if you're already using it in your firewall rules.) He's tested these rules on a Solaris 7 system and they seem to defeat the DoS. Note that you must be using Darren's IPFilter package for this to work. IPFW and some other firewalls do not remember the states of connections; they therefore can't detect the "established bistream shit" mentioned above. I'd recommend that all BSD users add Darren's rules as a first-pass fix for the problem. IPFilter also runs on Linux, but doesn't come with all distros. To get it, see http://cheops.anu.edu.au/~avalon/ --Brett Glass -- end snip -- I have gone ahead and attempted to go by what the documents are saying (including man pages and the like). However I receive messages like: (hist 535)# ipf -f /etc/rc.ipf open device: Device not configured ioctl(SIOCADDFR): Bad file descriptor Which of course this isn't very helpful since I wasn't really familiar with which device it used (didn't reaad the ipfstat man page yet at this point :) ) I went about finding out the hard way instead... /* First things first... * (hist 566)# uname -a * FreeBSD localhost 3.2-RELEASE FreeBSD 3.2-RELEASE #4: Tue Jan 4 14:23:39 EST 2000 * root@localhost:/usr/src/sys/compile/nj i386 */ (hist 535)# truss -o ipf.out ipf -fd /etc/rc.ipf open device: Device not configured ipf: fopen(d) failed: No such file or directory (hist 536)# more ipf.out syscall open("/dev/ipl",2,027757755604) errno 6 'Device not configured' syscall open("/dev/ipl",0,027757755604) errno 6 'Device not configured' syscall writev(0x2,0xbfbfd934,0x4) returns 35 (0x23) syscall __sysctl(0xbfbfd948,0x2,0x806bbbc,0xbfbfd950,0x0,0x0) returns 0 (0x0) syscall open("d",0,0666) errno 2 'No such file or directory' syscall write(2,0xbfbfd288,48) returns 48 (0x30) syscall exit(0x1) process exit, rval = 256 (hist 543)# cd /dev (hist 544)# ls ip* ipauth ipl ipnat ipstate (hist 545)# ls -al ipl crw------- 1 root wheel 79, 0 Jan 22 02:31 ipl (hist 540)# ipf -df /etc/rc.ipf open device: Device not configured add 80ac723c del 80ac723d parse [pass in all] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ioctl(SIOCADDFR): Bad file descriptor parse [block in proto tcp all head 3] 00 00 00 00 00 00 64 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0f 00 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ioctl(SIOCADDFR): Bad file descriptor parse [pass in proto tcp from any to any flags S keep state group 3] 00 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0f 00 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0a 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ioctl(SIOCADDFR): Bad file descriptor I grep'ed (-i) for ipl in LINT and the kernel configuration file with nothing explaining a kernel configurable parameter for this device. So, I admit Im not very keen on this ipl device. What should I do to get it configured correctly? Jim ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Today's errors, in contrast: Windows - "Invalid page fault in module kernel32.dll at 0032:A16F2935" UNIX - "segmentation fault - core dumped" Humanous Beingsus - "OOPS, I've fallen and I can't get up" ------------------------------- Jim Conner NOTJames jconner@enterit.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message