Re: ACK is being sent with a sequence of 0 every time.

[James Rogers <jamesmrogers () gmail com>]

Thanks for the other comment location and the revision log number.  I
will read that.

I'll try  get_random_u32() there to see what effect that has.

On Wed, Jun 13, 2012 at 3:47 PM, David Fifield <david () bamsoftware com> wrote:
> On Wed, Jun 13, 2012 at 03:35:50PM -0400, James Rogers wrote:
> > As I was working on the spurious port closed bug I noticed something
> > strange: we don't set a sequence number in the ACK packets we send.
> >
> > SENT (0.5123s) TCP 10.0.1.103:46853 > 74.207.254.18:80 A ttl=44
> > id=49043 iplen=40  >>>>>  seq=0  <<<< win=1024
> >
> > as you can see the seq=0.
> >
> > According to what I think I am reading ACK packets are supposed to
> > have a sequence number set too.   It is a big red flag to always be
> > sending the same seq number in the same kind of packet.
> >
> > In "scan_engine.cc" [Modified] line 3372 of 6239
> >
> > if (pspec->pd.tcp.flags & TH_ACK)
> >     ack = seq32_encode(USI, tryno, pingseq);
> > else
> >     seq = seq32_encode(USI, tryno, pingseq);
> >
> > So the ack packet will not set a sequence number.   When I tried this:
> >
> > if (pspec->pd.tcp.flags & TH_ACK)
> >     ack = seq32_encode(USI, tryno, pingseq);
> >
> > seq = seq32_encode(USI, tryno, pingseq);
> >
> > it worked in adding a seq to the ACK segment, but the send to 443 and
> > to 80 then had the same seq number, which would just be confusing.
> >
> > Would like input on how to proceed here.  Of if this is even a bug.
>
> There is a good reason for this. You probably saw the comment
> immediately above the code you quoted:
>
>    /* Normally we encode the tryno and pingseq in the SEQ field, because that
>       comes back (possibly incremented) in the ACK field of responses. But if
>       our probe has the ACK flag set, the response reflects our own ACK number
>       instead. */
>
> This goes along with another long comment in tcp_probe_match:
>
>    /* We are looking to recover the tryno and pingseq of the probe, which are
>       encoded in the ACK field for probes with the ACK flag set and in the SEQ
>       field for all other probes. According to RFC 793, section 3.9, under
>       "SEGMENT ARRIVES", it's supposed to work like this: If our probe had ACK
>       set, our ACK number is reflected in the response's SEQ field. If our
>       probe had SYN or FIN set (and not ACK), then our SEQ is one less than the
>       returned ACK value because SYN and FIN consume a sequence number (section
>       3.3). Otherwise, our SEQ is the returned ACK.
>
>       However, nmap-os-db shows that these assumptions can't be relied on, so
>       we try all three possibilities for each probe. */
>
> See also the long log message for r15986, where this change was introduced.
>
> So the encoded tryno and pingseq definitely need to go in the ack field
> for packets with the ACK flag set. I don't know if seq has to be 0 or
> not. If not, we can just set it with get_random_u32.
>
> David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/