Date: Fri, 21 Jan 2000 12:40:49 +1100 (Australia/NSW) From: Darren Reed <avalon@coombs.anu.edu.au> To: brett@lariat.org (Brett Glass) 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 Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Message-ID: <200001210140.MAA28168@cairo.anu.edu.au> In-Reply-To: <4.2.2.20000120180821.0188d5c0@localhost> from "Brett Glass" at Jan 20, 2000 06:12:37 PM
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001210140.MAA28168>