Re: [NSE] rpcinfo breaks when encountering TCP protocol 0

[Daniel Miller <bonsaiviking () gmail com>]

Tom,

That's interesting. It looks like the trouble is in this section of
rpc.lua, in the Portmap.Dump function:

      pos, program, version, protocol, port = bin.unpack(">IIII", data, pos)
      if ( protocol == Portmap.PROTOCOLS.tcp ) then
        protocol = "tcp"
      elseif ( protocol == Portmap.PROTOCOLS.udp ) then
        protocol = "udp"
      end

So if the protocol is not in our expected mapping, it gets used directly as
an integer. Protocol 0 probably does not mean IPv6 hop-by-hop, since that's
not really a transport protocol. It's listed in that registry because IPv6
uses the Next Header field for both extension headers (like hop-by-hop) and
transport protocol numbers (for the payload). In this case, protocol 0
probably means something else, but I can't figure it out from the RFC 1057.

How does the rpcinfo program handle this info? Can you include output from
"rpcinfo -p <target>" and "rpcinfo -s <target>"? The first one uses version
2 of the protocol, just like we do. The second one uses a newer version 3
or version 4 which contains strings instead of numbers for transports
(called "netid"). In the future, we might consider checking version 3 or 4
for this info, too.

Dan

On Sun, Apr 10, 2016 at 10:49 AM, Tom Sellers <nmap () fadedcode net> wrote:

> The following was opened as Github Issue 363 (
> https://github.com/nmap/nmap/issues/363 ).  The formatting is likely
> better there.
>
>
> The rpcinfo.nse script crashes when gathering information from certain
> IPv6 enabled installations even if the target is scanned via its IPv4
> address. This is due to the script trying to process an
> unexpected protocol type: 0. IP protocol ID 0 is HOPOPT / IPv6 Hop-by-Hop
> Option. Information on this can be found at the links at the bottom of this
> Issue. The code that is crashing performs actions
> that can be skipped for protocol 0 so working around it for this script is
> trivial. My concern is that this needs to be reviewed to ensure broader
> changes are implemented if required.
>
>
> Simplest command to reproduce
>
> nmap -n -d --script=rpcinfo.nse -p 111 <target>
>
>
> Error Message
>
> NSE: rpcinfo M:434AE38 against 192.168.270.10:111 threw an error!
> C:\Users\Test\Documents\nmap-7.12/scripts\rpcinfo.nse:97: port 'protocol'
> field must be "udp", "sctp" or "tcp"
> stack traceback:
>         [C]: in function 'get_port_state'
>         C:\Users\Test\Documents\nmap-7.12/scripts\rpcinfo.nse:97: in
> function <C:\Users\Test\Documents\nmap-7.12/scripts\rpcinfo.nse:84>
>         (...tail calls...)
>
>
> The relevant code is line 97 in rpcinfo.nse:
>
> 96    for proto, v2 in pairs(v) do
> 97      local nmapport = nmap.get_port_state(host, {number=v2.port,
> protocol=proto})
> 98      if nmapport and (nmapport.state == "open" or nmapport.state ==
> "open|filtered") then
>
> Direct link:
> https://github.com/nmap/nmap/blob/0ac6e525237300792f12b74c35e75c171b5ce3ea/scripts/rpcinfo.nse#L96-L98
>
>
>
> Here is an example of the variable v that the code is iterating over:
>
> udp:
>   version:
>     1: 2
>     2: 3
>     3: 4
>   port: 111
> tcp:
>   version:
>     1: 2
>     2: 3
>     3: 4
>   port: 111
> 0:
>   version:
>     1: 2
>     2: 3
>     3: 4
>   port: 111
>
>
> When nmap.get_port_state gets called with protocol 0 from variable 'v'
> above it triggers this section of code in nse_utility.cc:
>
> 196 protocol = strcmp(lua_tostring(L, -1), "tcp") == 0 ? IPPROTO_TCP :
> 197            strcmp(lua_tostring(L, -1), "udp") == 0 ? IPPROTO_UDP :
> 198            strcmp(lua_tostring(L, -1), "sctp") == 0 ? IPPROTO_SCTP :
> 199            luaL_error(L, "port 'protocol' field must be \"udp\",
> \"sctp\" or \"tcp\"");
>
> Direct link:
> https://github.com/nmap/nmap/blob/0ac6e525237300792f12b74c35e75c171b5ce3ea/nse_utility.cc#L196-L199
>
> This code is unable to account for a protocol name of '0' and so generates
> the error.
>
> As I said at the start, it's trivial to work around this in rcpinfo.nse.
> My concern is that other sections of code may need to be adjusted as well.
>
> Thoughts?
>
> Tom
>
>
>
> Reference:
>
> IP Protocol number list
> https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers
>
> Assigned Internet Protocol Numbers
> http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
>
> IP Protocol 0, Hop by Hop Options
>
> https://en.wikipedia.org/wiki/IPv6_packet#Hop-by-hop_options_and_destination_options
>
> RCF 2460, Page 11, Section 4.3 - Hop-by-Hop Options Header
> http://tools.ietf.org/html/rfc2460#page-11
> _______________________________________________
> Sent through the dev mailing list
> https://nmap.org/mailman/listinfo/dev
> Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/