-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I have located the error.
main.cc calls srand() properly but later code calls it again.
To generate a random IP address a random u32 is generated
(get_random_u32()) which in turn gets the random bytes via a call to
get_random_bytes() in nbase/nbase_rng.cc.
get_random_bytes attempts to use one of /dev/{a,u,}random to get the
bytes and if opening those fail, falls back onto rand().
The issue is that when the fallback is used, srand() is always re-called
like so:
/* Seed our random generator */
gettimeofday(&tv, NULL);
srand((tv.tv_sec ^ tv.tv_usec) ^ getpid());
The problem here is that the rng is being seeded with time every time it
is called. Time is pretty biased and will generate a collision which
will create a cycle in the prng (calls to rand()).
The solution to this is to drop the re-seeding code starting at line
184 of nbase/nbase_rng.cc (it is redundant and done in main.cc).
This issue only shows up on OSes that do not offer randomness
from /dev/...
Brandon
On Wed, 23 Apr 2008 18:14:53 -0700
Fyodor <fyodor_at_insecure.org> wrote:
> On Thu, Apr 24, 2008 at 01:15:36AM +0100, jah wrote:
> >
> > With nmap -n -sL -iR 500 I find there's an average (mean) of 143
> > duplicate targets generated (std. deviation approx 5).
>
> Wow, I can reproduce the same thing on Windows. I used this command
> under cygwin to count the number of uniq IPs for a given -iR size:
>
> nmap -n -sL -iR NNN | egrep '^Host ' | sort | uniq | wc
>
> Wher 'NNN' is replaced with the number of hosts to try. Here are the
> results:
>
> 100 -> 100
> 200 -> 200
> 300 -> 300
> 400 -> 348
> 500 -> 359
> 600 -> 352
> 700 -> 356
> 800 -> 430
> 900 -> 528
> 1000 -> 646
>
> So these are about the same results as you saw. This is Windows XP
> SP2 running on VMWare using our stock 4.60 binary. I tried the same
> command on Linux and much more expected and proper numbers:
>
> 1000 -> 1000
> 10000 -> 10000
> 100000 -> 100000
> 500000 -> 499958
>
> Something is broken or poorly implemented in either Windows' rand() or
> the way Nmap is using it.
>
> > I'd be very interested to know if anyone else can reproduce the
> > issue and any pointers to where I might look next.
>
> I'm not sure, but please let us know if you figure this out.
>
> Cheers,
> -F
>
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://SecLists.Org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFID+hvqaGPzAsl94IRAgXXAJ92oMl4t7rc0557GCXT1PYWzLWyIgCgjA3h
fI6PSpR4SAUgXivwTBByi+4=
=F+8s
-----END PGP SIGNATURE-----
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org
Received on Apr 23 2008
Intro
