Date: Fri, 21 Jan 2000 06:55:15 -0800 From: gdonl@tsc.tdk.com (Don Lewis) To: Darren Reed <avalon@coombs.anu.edu.au>, brett@lariat.org (Brett Glass) Cc: security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <200001211455.GAA13013@salsa.gv.tsc.tdk.com> In-Reply-To: Darren Reed <avalon@coombs.anu.edu.au> "Re: stream.c worst-case kernel paths" (Jan 21, 3:17pm)
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 21, 3:17pm, Darren Reed wrote: } Subject: Re: stream.c worst-case kernel paths } In some mail from Brett Glass, sie said: } > } > I've been browsing the code, and have seen two possible places where } > the code might be improved to lessen the impact of this DoS. Folks } > who know the stack better may know about details and side effects } > that I don't, so so if my analysis has holes in it please don't chew } > me out TOO badly. } > } > From /sys/netinet/tcp_input.c: } > } > The kernel seeks a socket that matches the packet. It fails, of course, } > to find an open socket. } > } > inp = in_pcblookup_hash(&tcbinfo, ti->ti_src, ti->ti_sport, } > ti->ti_dst, ti->ti_dport, 1); } } > If the system isn't listening on the port, inp is set to NULL. But inside } > in_pcblookup_hash, we've had to do two hash table lookups, because } > the "wildcard" flag is set to 1. (Suggested improvement: turn off the } > wildcard search if the packet is not a SYN. I mentioned this on -current in my comments on Alfred Perlstein's suggested patch. I think I'll amend my comment, since I now think the wildcard lookup should only be done in the SYN & !ACK case. } >I suppose that if the } > packet IS a SYN, we still have to test to see if it was erroneously } > sent in the middle of a connection, so we really have to do both tests } > in that case. See in_pcb.c.) I believe this is correct. } Also, what about the simultaneous connection problem ? (both ends send } SYN's to the other, same ports). I don't think this suggested change affects simultaneous opens since the first (non-wildcard) hash lookup should succeed. > Trouble is, a smart attacker will fire the barrage at a port on which the machine is > listening. This makes the code path longer because the hash table lookup will succeed. Good catch. I figured that skipping the extra hash lookup would be a good optimizatin, but I didn't notice this problem. 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?200001211455.GAA13013>