mailing list archives
Re: [Bug]? -iR <num_hosts> on windows XP generates duplicate targets
From: Kris Katterjohn <katterjohn () gmail com>
Date: Thu, 01 May 2008 23:41:52 -0500
-----BEGIN PGP SIGNED MESSAGE-----
Brandon Enright wrote:
But what are the odds of you mentioning this hanging so soon after
this (bit hostile) email which mentions the exact behavior Nmap
exhibits when I only use /dev/random?
I followed your link because I don't recall that email but I don't think
you got the link correct since I don't see any mention of /dev/random
and the "... -iR 10000 .. (No response)" on the page is probably some
Actually, I had misread his email. I was referring to the hanging
possibly being caused by a missing urandom, which caused random to be
used. The similarity I mentioned is the immediate hanging I describe below.
Apparently his Linux box
doesn't have urandom (or it's a very strange coincidence since I've
never had Nmap just hang immediately for any other reason..)
Nmap gets a few random numbers for sequence numbers and such. Have you
tested the effect of /dev/random on a regular scan? /dev/random should
have 512 bytes available at the start of the scan which should last a
Here's a snip from an strace of just "nmap localhost" run as root:
open("/dev/random", O_RDONLY) = 3
[snip a few lines with fstat64, ioctl and mmap2]
read(3, <random data>..., 4096) = 35
This happens immediately after starting. Without strace Nmap just sits
there seemingly idle.
The effects are very similar when run as a normal user, but it usually
does a few smaller read()s.
read()s do eventually come (after a while), typically in increments of
8, but this happens immediately even with such a simple command. The
ol' "shake your mouse around or type" does speed it up.
Given the options of /dev/random, rand() and OpenSSL, it looks like
rand() may be the answer since random hangs and OpenSSL was slow.
There is a compromise that I think is a better option than rand() that
I'll comment on below.
All my ranting really comes down to this: we can create nmap_rand() and
nmap_rand_seed() routines that will work on all 32 (and higher bit)
computers using less than a dozen lines of C. Doing this will provide
a good fast compromise if we can't/don't use OpenSSL/dev-random/rand()/etc.
I'll code up and test a patch to implement this over the weekend.
PRNGs haven't really been my thing, but this thread has gotten me mighty
interested in them :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Sent through the nmap-dev mailing list
Archived at http://SecLists.Org