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

[Kris Katterjohn <katterjohn () gmail com>]

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