Re: Raw IP NSE Functionality

[David Fifield <david () bamsoftware com>]

On Tue, Feb 23, 2010 at 03:00:17PM -0600, Kris Katterjohn wrote:
> On 02/23/2010 01:39 PM, Patrick Donnelly wrote:
> > Ok this patch wasn't quite right. I've attached a new one but I'm
> > getting some strange C++ segfault I can't figure out. I'm not going to
> > devote any more time to this since Kris has a viable patch already
> > committed.
>
> Ah, yes, sorry about not mentioning this before you posted.  I wanted to put
> it in there before I got busy today (i.e. right after I committed).  I didn't
> mention it yet because I ended up finding a bug and wanted to investigate first.
>
> I don't know if my script is somehow wrong, if it's a bug in the pcap reading,
> or something entirely different. Using ipidseq on multiple hosts at the same
> time (hostgroup) somehow gives my script a packet with the same ipid as (what
> appears to be) the first packet read from the first host read from in the
> group.  It's only the first one, the others are ipids from the real host.
> This sounds horribly confusing after I read it, so here's something better
> than my explanation (stripped Nmap output with some debugging in script):
>
> NSE: Starting ipidseq against 192.168.10.4.
> NSE: Starting ipidseq against 192.168.10.3.
> got ipid 49992 from 192.168.10.4:21
> got ipid 49992 from 192.168.10.3:80
> got ipid 49994 from 192.168.10.3:80
> got ipid 38558 from 192.168.10.4:21
> got ipid 49996 from 192.168.10.3:80
> got ipid 38559 from 192.168.10.4:21
> got ipid 49998 from 192.168.10.3:80
> got ipid 38560 from 192.168.10.4:21
> got ipid 50000 from 192.168.10.3:80
> got ipid 38561 from 192.168.10.4:21
> got ipid 50002 from 192.168.10.3:80
> ipid #1 = 49992
> ipid #2 = 49994
> ipid #3 = 49996
> ipid #4 = 49998
> ipid #5 = 50000
> ipid #6 = 50002
> NSE: Finished ipidseq against 192.168.10.3.
> got ipid 38562 from 192.168.10.4:21
> ipid #1 = 49992
> ipid #2 = 38558
> ipid #3 = 38559
> ipid #4 = 38560
> ipid #5 = 38561
> ipid #6 = 38562
> NSE: Finished ipidseq against 192.168.10.4.
>
> Nmap scan report for 192.168.10.3
> Host script results:
> |_ipidseq: Incremental! [used port 80]
>
> Nmap scan report for 192.168.10.4
> Host script results:
> |_ipidseq: Randomized [used port 21]
>
>
> Notice the same "ipid #1" lines for the hosts.

I have this fixed in r16879. Man, you had me deep in the Nsock pcap code
before I thought to look at this:

--- scripts/ipidseq.nse (revision 16878)
+++ scripts/ipidseq.nse (revision 16879)
@@ -215,8 +215,6 @@

        pcap:set_timeout(3000)

-       math.randomseed(os.time())
-
        local tcp = genericpkt(host, port)

        while i <= NUMPROBES do

os.time has a resolution of one second, so most of the time both scripts
had the same random seed. The first random number they generated was the
source port for the first probe, which would be the same in both
scripts. Therefore both scripts registered the same pcap key and both
saw the same one out of the two reply packets. The fe times when there
was no collision, the two calls to math.randomseed must have fallen on
either side of a second boundary.

The BPF filter alone won't prohibit one script from receiving another
script's packets. As I understand it, that's the purpose of the extra
pcap_register step. You could make the matching more robust by
registering all the information that you currently have in the BPF,
which is the source and destination hosts as well as the source port.

This all looks good an ready to merge, once you add documentation for
the nmap.get_ports function to nmap.luadoc and scripting.xml.

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