From owner-freebsd-security  Fri Jan 21  6:55:40 2000
Delivered-To: freebsd-security@freebsd.org
Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21])
	by hub.freebsd.org (Postfix) with ESMTP id EC8D91544D
	for <security@FreeBSD.ORG>; Fri, 21 Jan 2000 06:55:32 -0800 (PST)
	(envelope-from gdonl@tsc.tdk.com)
Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198])
	by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id GAA05719;
	Fri, 21 Jan 2000 06:55:16 -0800 (PST)
	(envelope-from gdonl@tsc.tdk.com)
Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194])
	by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id GAA47668;
	Fri, 21 Jan 2000 06:55:16 -0800 (PST)
	(envelope-from Don.Lewis@tsc.tdk.com)
Received: (from gdonl@localhost)
	by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id GAA13013;
	Fri, 21 Jan 2000 06:55:16 -0800 (PST)
Message-Id: <200001211455.GAA13013@salsa.gv.tsc.tdk.com>
From: gdonl@tsc.tdk.com (Don Lewis)
Date: Fri, 21 Jan 2000 06:55:15 -0800
In-Reply-To: Darren Reed <avalon@coombs.anu.edu.au>
       "Re: stream.c worst-case kernel paths" (Jan 21,  3:17pm)
X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98)
To: Darren Reed <avalon@coombs.anu.edu.au>,
	brett@lariat.org (Brett Glass)
Subject: Re: stream.c worst-case kernel paths
Cc: security@FreeBSD.ORG
Sender: owner-freebsd-security@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

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