Home page logo
/

nmap-dev logo Nmap Development 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-----
Hash: SHA1

Brandon Enright wrote:
But what are the odds of you mentioning this hanging so soon after
this (bit hostile) email[1] 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
other issue.


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
while.


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
read(3,
 <unfinished ...>

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.

<big snip>
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 :)

Brandon


Thanks,
Kris Katterjohn

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBSBqbjv9K37xXYl36AQLSFA/9EzhWlsRJlrPH+e4xx6aPHMnnh2y5bwOE
iEGnIkfZRZHG14cJcwg3sFpiE44frog4kQGIH07RnPNkoTU+nVb7h6wUhgmDnWk0
pUkZiz3gTzAuYyv0RHj5UJAF7OJPgyFvOgGoNBm2lHKEwU1ssLa9VhnkrPcTuFSt
5Y4LDTZdh/w/jKLhczFgqZUybGR++jnM5erEhrwuD0CT1kaofpjngRGp74TKW7Ax
/npoyluX4OwAo9tASy/lS5MeFQB/L5+sSB+2EEKMX6JrITyHtxL6eMiVHnSYeoYj
IF7V9yb3h6aSwZUxmCcoC9EsdWvmcKDTpJ+MDybod3VTCRTY+LagpzsIz/BZ6Y1e
6NidG631NT2EamV/krroDOwjBdaRof0p9pZTO9H2TUfAohpHzQDpvomjMmmqbkpV
NHhokHHLGXSm92bfZgnMVTQs8T3rShxpmDMiumtqm1YrQ22b41TL6zbIdVZplyKf
IAJi4vlVaFp7lP7u6/EHFfOjJNRKnt8RpYmuRPnLK/wqRDcbrsPAbBojQxFsFWNv
JqK6u60cZ1heWSta+Myl7ySU6xp3VKDJeelY77nSyQj9r6okGhLDuGMSG8Zu51Ti
heeoEP2xBunSW+DcSPuMrig1Mphj7H9Gfv0GkdMasMitFAiDKYdPZb4GFooII1jG
a5a/2eMUM0Q=
=XFw2
-----END PGP SIGNATURE-----

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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]