From owner-freebsd-security Fri Jan 21 8:54:33 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 110DD154A5 for ; Fri, 21 Jan 2000 08:54:31 -0800 (PST) (envelope-from brett@lariat.org) Received: from workhorse (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id JAA20442; Fri, 21 Jan 2000 09:54:20 -0700 (MST) Message-Id: <4.2.2.20000121094204.01a57d50@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 09:54:16 -0700 To: Jeroen Ruigrok/Asmodai From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: Darren Reed , security@FreeBSD.ORG In-Reply-To: <20000121102908.A4494@daemon.ninth-circle.org> References: <4.2.2.20000120212336.01882220@localhost> <4.2.2.20000120182425.01886ec0@localhost> <200001210417.PAA24853@cairo.anu.edu.au> <4.2.2.20000120212336.01882220@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 02:29 AM 1/21/2000 , Jeroen Ruigrok/Asmodai wrote: > >The odds of the source ports being the same are minuscule. Wouldn't this > >prevent a problem? Or am I misunderstanding the implications here? > >Stevens' TCPv1, Chapter 18.8. > >Although I am not sure about the implications of the exact same numbered >source ports. If that is what Darren is saying. Could also be the same >destination ports. Let's recap. We were discussing the code for in_pcblookup_hash() in the file in_pcb.c, and the code which calls it in tcp_input.c. I noted that when a TCP packet comes in, the code searches for an associated socket with the call inp = in_pcblookup_hash(&tcbinfo, ti->ti_src, ti->ti_sport, ti->ti_dst, ti->ti_dport, 1); Note that the last parameter, "wildcard," is always set to 1. This means that two lookups are done if necessary. in_pcblookup_hash first looks for an already open socket, and if that fails it looks for a listener. This second search (badly named, IMHO; it should really say something like "lookforlistener") is done only if the "wildcard" flag is set. What I said was that we should only be looking for a listener if the packet is a SYN; that is, if SYN is set and RST and ACK (and, probably, FIN too) are clear. If it's not something that can start a connection, I can't see why looking for a listener is productive. Darren said that this might cause problems in the case of simultaneous attempted connections in both directions, but I couldn't see how. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message