[NSE] - banner.nse: UDP banner grabbing, comm.lua and nsock_core.c

[jah <jah () zadkiel plus com>]

Hi folks,

So I've been trying to get a good set of socket timeout values for
banner.nse and I found that comm.get_banner doesn't send udp packets. 
Actually, first off I realised that banner.nse was passing an
incorrectly named parameter to get_banner (opts.protocol instead of the
correct opts.proto) and it was always using proto tcp (whoops).  That
aside, I found that socket:connect() gets a successful callback, but
it's not until one does a socket:send() that a udp datagram is sent -
which seems to make sense for the udp protocol, no?

So I patched comm.lua to test for the protocol and perform comm.exchange
with an empty string for data if proto is udp.  Trying it out resulted
in following assertion failure:

nmap: nsock_core.c:388: handle_write_result: Assertion `bytesleft > 0'
failed.
Aborted

I changed the assertion in handle_write_result to bytesleft >= 0 and
this allowed a udp datagram to be sent.

I thought that if nse->writeinfo.written_so_far is ever more than 0 when
bytesleft is calculated:

bytesleft = FILESPACE_LENGTH(&nse->iobuf) - nse->writeinfo.written_so_far;

the changed assertion might allow unnecessary writes of zero bytes and
that in these cases we should still assert bytesleft > 0.  So this might
be better:

assert(bytesleft >= (nse->writeinfo.written_so_far > 0)?1:0);

I haven't managed to get written_so_far to be anything but zero and I
don't know if it's ever likely to be.  So maybe bytesleft >= 0 will do
just as well.

All of that aside, I started to wonder whether banner grabbing for udp
might be a bit pointless.  I note that there's no NULL probes for UDP in
nmap-service-probes and so far, with the exception of chargen, I've
found zero udp services that respond to an empty datagram.

What do you think - should we prevent comm.get_banner from wasting time
doing a connect() for udp, and forget udp banner grabbing or should we
patch comm and nsock_core.c to allow it?

Regards,

jah

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org