Nmap Development mailing list archives
Re: nmap 6.47 compile failure on AIX 7100-03
From: Daniel Miller <bonsaiviking () gmail com>
Date: Wed, 10 Sep 2014 13:50:42 -0500
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.orgLooking 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/
Current thread:
- nmap 6.47 compile failure on AIX 7100-03 Kevin Brott (Sep 02)
- Message not available
- Message not available
- Re: nmap 6.47 compile failure on AIX 7100-03 Daniel Miller (Sep 08)
- Re: nmap 6.47 compile failure on AIX 7100-03 Daniel Miller (Sep 10)
- Re: nmap 6.47 compile failure on AIX 7100-03 Daniel Miller (Sep 10)
- Re: nmap 6.47 compile failure on AIX 7100-03 Daniel Miller (Sep 10)
- Re: nmap 6.47 compile failure on AIX 7100-03 Kevin Brott (Sep 10)
- Re: nmap 6.47 compile failure on AIX 7100-03 Daniel Miller (Sep 10)
- Re: nmap 6.47 compile failure on AIX 7100-03 Kevin Brott (Sep 10)
- Re: nmap 6.47 compile failure on AIX 7100-03 Daniel Miller (Sep 10)
- Re: nmap 6.47 compile failure on AIX 7100-03 Kevin Brott (Sep 10)
- Re: nmap 6.47 compile failure on AIX 7100-03 Daniel Miller (Sep 17)
- Re: nmap 6.47 compile failure on AIX 7100-03 Kevin Brott (Sep 17)
- Message not available
- Message not available