[Bug]? -iR <num_hosts> on windows XP generates duplicate targets

[jah <jah () zadkiel plus com>]

Greets,

I'm having a hard time getting to the bottom of this one...

With nmap -n -sL -iR 500 I find there's an average (mean) of 143
duplicate targets generated (std. deviation approx 5).
nmap -n -sL -iR 1000 -> 348 mean duplicates (std. dev. approx. 11).
Around num_hosts = 340 I might see 1 duplicate in 10 passes.  Below 300
I haven't seen any.  Above 400 is where the duplicates start to get
significant.

This occurs on XP SP1, SP2 and SP3 with the official release of 4.60 as
well as builds from svn.
The SP1 machine I've used is a bare windows installation with no
software other than nmap (and nmaps winpcap).
SP2 machine has VS2005 and VC++ 2005 and 2008 Express Editions.
SP3 machine has VC++ 2005 Express Edition.

I spent some time stepping through the code in VC++ 2005EE to understand
what happens with -iR and couldn't find any issue with the way
bytebuf[2048] in nbase_rnd.c is filled with calls to rand() (in
C:\Program Files\Microsoft Visual Studio 8\VC\crt\src\rand.c).
I watched as bytebuf was refilled after 512 calls (2048/4bytes requested
in each call) to get_random_bytes() and verified that the random data
was different each time.
I then realised that the issue doesn't occur in the DEBUG configuration
- no duplicated IP's.  This has to be significant, and I thought it
might be due to the MS common runtime, but I'm really not sure given the
various machines I've tried it on.

An interesting and perhaps telling observation is that in one particular
instance, with 1000 targets, the order of targets generated was:
targets 1-359 followed by
targets 360-717 which duplicate the first 358 exactly (same order) and
were followed by
targets 718-1000 unique targets
...so, two blocks of 358 duplicated targets separated by a single unique
one and followed by 283 more unique ones.  WTF?

Another observation was that out of a single use of bytebuf (512 IP's)
169 were discarded leaving 343 non-reserved.  This is roughly of the
order of duplicates.  Roughly.

I wasn't able to get any useful information using depends.exe profiling,
with -n -sL -iR <num_hosts> arguments to nmap.

I'd be very interested to know if anyone else can reproduce the issue
and any pointers to where I might look next.

Regards,

jah



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