Re: nmap 6.47 compile failure on AIX 7100-03

[Daniel Miller <bonsaiviking () gmail com>]

On Wed, Sep 10, 2014 at 1:17 PM, Daniel Miller <bonsaiviking () gmail com>
wrote:

> On Wed, Sep 10, 2014 at 12:05 PM, Daniel Miller <bonsaiviking () gmail com>
> wrote:
>
> > * Features involving libpcap do not seem to work outside localhost, but
> > that may be an artifact of my environment. If you can, please try this
> > command out (as root) and reply with the output: nmap -A -d
> > scanme.nmap.org
>
> Looking for a response from some other devs on the mailing list for this
> one:
>
> Ok, the reason this is failing on my system is that the SYNACK response
> has some odd TCP options that fail validation in validateTCPhdr() in
> tcpip.cc. Specifically, the options section is:
>
> 0204 0564 010e 0303
>
> with a 2-byte trailer outside the packet boundary that is random. The
> "0204 0564" is MSS, and parses just fine. Then there's a NOP "01" followed
> by an unknown option "0e". validateTCPhdr() skips this like a NOP, then
> finds "0303" which is Window Scale and should be followed by a 1-byte
> value. However, that's the end of the packet and so it's invalid.
> Wireshark/tcpdump treat "0e" as an "unknown option" and assume it takes up
> the next 2 bytes (or the rest of the packet).
>
> Given this, perhaps we should adopt a similar validation mechanism? The
> extra data appears to be added to SYNACK responses to -sT, also, and those
> work just fine, so it's not hampering a TCP connection. Thoughts?
>
> Dan

Some more background:

If TCP option 0x0e is a multibyte option, then the second byte (0x03) would
say how many bytes it takes up. This works out, and the packet would
validate. Indeed, the obsoleted RFC 1146 specifies TCP option 14 as an
"alternative checksum", with a size of 3 bytes. The value 0x03 in the last
position means "Redundant Checksum Avoidance", but we don't really care
about that. So we *could* add in the few known single-byte options and then
change the default (unknown option) handling to assume a multibyte option
with the length as the second option.

Another more complicated alternative would be to validate as we currently
do (single-byte unknowns), then if there's a problem, go back through with
the multibyte strategy and see if that validates.

In the meantime, I've added this (0x0e) option as a 3-byte option, since it
appears this is an artifact of some tcp checksum offloading. See
ftp://ftp.ucsd.edu/pub/csl/fastnet/faq.txt for more info.

So now -sS works, and -O appears to work. --traceroute produces a hang,
though.

Dan
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/