Date: Fri, 21 Jan 2000 15:17:34 +1100 (Australia/NSW) From: Darren Reed <avalon@coombs.anu.edu.au> To: brett@lariat.org (Brett Glass) Cc: security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <200001210417.PAA24853@cairo.anu.edu.au> In-Reply-To: <4.2.2.20000120182425.01886ec0@localhost> from "Brett Glass" at Jan 20, 2000 08:17:30 PM
next in thread | previous in thread | raw e-mail | index | archive | help
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 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.)
Also, what about the simultaneous connection problem ? (both ends send
SYN's to the other, same ports).
> Back to tcp_input.c. We then execute the following:
>
> if (inp == NULL) {
> if (log_in_vain && tiflags & TH_SYN) {
> char buf[4*sizeof "123"];
>
> strcpy(buf, inet_ntoa(ti->ti_dst));
> log(LOG_INFO,
> "Connection attempt to TCP %s:%d from %s:%d\n",
> buf, ntohs(ti->ti_dport), inet_ntoa(ti->ti_src),
> ntohs(ti->ti_sport));
> }
> }
> #ifdef ICMP_BANDLIM
> if (badport_bandlim(1) < 0)
> goto drop;
> #endif
> goto dropwithreset;
> }
>
> Normally, we'll wind up at the label "dropwithreset", which means we'll
> send back a RST. This suggests that restricting RSTs will help with the
> DoS. (Does anyone know if not sending an RST violates any RFCs if there
> was never a connection?)
Yes. RFC 793, figure 11, page 35, describes the prescribed behaviour.
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?200001210417.PAA24853>