From owner-freebsd-security Thu Jan 20 17:41:45 2000 Delivered-To: freebsd-security@freebsd.org Received: from cairo.anu.edu.au (cairo.anu.edu.au [150.203.224.11]) by hub.freebsd.org (Postfix) with ESMTP id A9D6F14E57; Thu, 20 Jan 2000 17:41:19 -0800 (PST) (envelope-from avalon@cairo.anu.edu.au) Received: (from avalon@localhost) by cairo.anu.edu.au (8.9.3/8.9.3) id MAA28168; Fri, 21 Jan 2000 12:40:50 +1100 (EST) From: Darren Reed Message-Id: <200001210140.MAA28168@cairo.anu.edu.au> Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? To: brett@lariat.org (Brett Glass) Date: Fri, 21 Jan 2000 12:40:49 +1100 (Australia/NSW) Cc: avalon@coombs.anu.edu.au (Darren Reed), imp@village.org (Warner Losh), jamiE@arpa.com (jamiE rishaw - master e*tard), tom@uniserve.com (Tom), mike@sentex.net (Mike Tancsa), freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, security-officer@FreeBSD.ORG In-Reply-To: <4.2.2.20000120180821.0188d5c0@localhost> from "Brett Glass" at Jan 20, 2000 06:12:37 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from Brett Glass, sie said: > > At 06:03 PM 1/20/2000 , Darren Reed wrote: > > >If you're using "flags S keep state" or "flags S/SA keep state", > >then as far as I'm aware, having read the code, you are safe. > > This might be a workaround. What rule(s) would have to follow it > to block the ACK? None. > >I'm intrigued to know what the bug is. Reading the code, it is > >hard to see how you could make a box fall over using it, unless > >there were some serious problems in how random TCP ACK's were > >handled. > > My guess is that there's a long code path, or other inefficiency, > in the way the ACK is handled. Perhaps a linear search for the > right socket instead of one that's more clevery implemented > (e.g. search by port, then address, etc.). Well, it does bring Solaris7 to a point where it runs _very_ slowly: # ping -s 10.100.1.2 PING 10.100.1.2: 56 data bytes 64 bytes from solaris7 (10.100.1.2): icmp_seq=0. time=2. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=1. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=2. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=3. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=4. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=5. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=6. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=7. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=8. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=9. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=10. time=0. ms -- start 64 bytes from solaris7 (10.100.1.2): icmp_seq=11. time=11. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=12. time=16. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=13. time=16. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=14. time=18. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=15. time=21. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=17. time=23. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=19. time=25. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=22. time=29. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=28. time=21. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=36. time=0. ms -- end 64 bytes from solaris7 (10.100.1.2): icmp_seq=37. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=38. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=39. time=0. ms ^C ----10.100.1.2 PING Statistics---- 40 packets transmitted, 24 packets received, 40% packet loss round-trip (ms) min/avg/max = 0/7/29 # FWIW, the box sending the ping's and solaris7 are 100BaseT but the attacker is only 10BaseT. Besides the issue of time to process TCP packets, there is also basic network flooding happening here too. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message