[7837] in bugtraq

home help back first fref pref prev next nref lref last post

Re: FreeBSD's RST validation

daemon@ATHENA.MIT.EDU (Bruce A. Mah)
Tue Sep 1 14:26:49 1998

Date: 	Mon, 31 Aug 1998 13:26:28 -0700
Reply-To: bmah@CA.Sandia.GOV
From: "Bruce A. Mah" <bmah@CA.SANDIA.GOV>
X-To:         Don Lewis <Don.Lewis@tsc.tdk.com>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To:  Your message of "Mon, 31 Aug 1998 11:55:07 PDT." 
              <199808311855.LAA28095@salsa.gv.tsc.tdk.com>

If memory serves me right, Don Lewis wrote:

> On Aug 31, 11:24am, Bruce A. Mah wrote:

[snip]

> }             if (tiflags & TH_RST) {
> } !                   if ((tiflags & TH_ACK) &&
> } !                   /* XXX outside window? XXX */
> } !                       (SEQ_GT(ti->ti_ack, tp->iss) &&
> } !                        SEQ_LEQ(ti->ti_ack, tp->snd_max)))
> }                             tp = tcp_drop(tp, ECONNREFUSED);
> }                     goto drop;
> }             }
>
> As more data is sent across the connection, the wider the window for
> a spoofed RST opens.  Once you send 2 GB, legitimate RSTs no longer
> work.  You should probably be comparing against tp->snd_una instead
> of tp->iss.

Hmmm.  I was thinking specifically of the problem that with a RST arriving for
a connection in SYN_SENT, the ACK in the RST-bearing segment has to
acknowledge the initial SYN (thus, a test against tp->iss).  I hadn't thought
that the ever-increasing difference between tp->snd_una and tp->iss would be a
problem, since at this point in the code, we know that the receiving end of
the connection is in SYN_SENT, as opposed to, say, ESTABLISHED.  Shouldn't
(tp->snd_una == tp->iss) in this state, in which case, either would do?  (Not
trying to split hairs, but just trying to learn a little more.)

Thanks,

Bruce.

home help back first fref pref prev next nref lref last post