Re: Weird Crash - "WAITING_TO_RUNNING"

[Nathan <nathan.stocks () gmail com>]

On Wed, Nov 3, 2010 at 1:33 PM, Nathan <nathan.stocks () gmail com> wrote:
> On Wed, Nov 3, 2010 at 11:29 AM, Patrick Donnelly <batrick () batbytes com> wrote:
> > On Wed, Nov 3, 2010 at 1:07 PM, Nathan <nathan.stocks () gmail com> wrote:
> > > "Is this on a 32-bit machine?" -- The hardware is 64-bit capable, but
> > > the old version of linux on it is compiled in 32-bit, I think.  The OS
> > > can address more than 4GB RAM, but the stuff running on it seems to
> > > act very 32-bit.  Python's maxint is 32-bit, anyway:
> > >
> > > $ python
> > > Python 2.5.2 (r252:60911, Oct 30 2008, 18:03:18)
> > > [GCC 4.1.2 (Gentoo 4.1.2 p1.1)] on linux2
> > > Type "help", "copyright", "credits" or "license" for more information.
> > > > > > import sys
> > > > > > sys.maxint
> > > 2147483647
> > >
> > > $ uname -a
> > > Linux scan5 2.6.23-gentoo-r9 #4 SMP Tue Oct 12 16:02:12 MDT 2010 i686
> > > Intel(R) Xeon(R) CPU E5507 @ 2.27GHz GenuineIntel GNU/Linux
> >
> > Your processor (running as 32 bit) is using PAE (Physical Address
> > Extension) to allow more than 4GB of RAM. Your process is still only
> > allowed ~4GB of addressable RAM. This is why Nmap is crashing for you.
>
> Okay, I'll buy that that is the _symptom_ we're seeing.  I can't
> imagine you're trying to imply that it's normal for an nmap scan of
> one target to take that much RAM, though.  At 65,535 ports, 4GB gives
> you 64KB PER PORT.  I could generate a small jpeg thumbnail of the
> traffic sent to each port at that rate.
>
> The question is, WHAT is using up that RAM, and how do we stop it?   I
> could run multiple instances of this same scan on this same box with
> nmap 4.68 (that I just upgraded from) against this target without any
> problems at all.
>
> Did anyone look at the stack trace???  It seriously can't be normal to
> run "skypev2-version" and "jdwp-version" tens of thousands of times
> until you run out of RAM.  Infinite loop, anyone?  Or, perhaps this is
> caused by nmap erroneously thinking every single port is open (which
> is one of the things I hoped upgrading would fix), where the
> underlying assumption is that very few ports will be open so we can
> use a ton of memory to investigate each open port?
>
> ~ Nathan

Found a workaround:  add "--scan-delay 1ms".  It finishes a lot
quicker too.  It seems much more accurate too.  At least it has a lot
less than 65,535 ports listed as open like nmap 4.68 thought.

So now my question is: According to the nmap man page, nmap will "try"
to dynamically determine an appropriate delay time, but it's unclear
as to whether specifying this option overrides that dynamic
determination completely or if it just sets a starting point that will
still be dynamically adjusted if it thinks is necessary.  Does anyone
know which behavior I just described matches reality?

If specifying "--scan-delay" overrides the dynamic determination
completely, then I'll need to do some careful testing of appropriate
values, because I may not want to blindly add this option to all the
hosts that I need to scan.

/usr/bin/sudo /usr/bin/nmap --scan-delay 1ms -sS -sV -T4 -p 1-65535
74.62.92.70 -P0

Starting Nmap 5.35DC1 ( http://nmap.org ) at 2010-11-03 14:21 MDT
Nmap scan report for remote.tjwels.net (74.62.92.70)
Host is up (0.076s latency).
Not shown: 65523 closed ports
PORT     STATE    SERVICE       VERSION
20/tcp   filtered ftp-data
21/tcp   filtered ftp
25/tcp   open     smtp          Microsoft ESMTP
53/tcp   open     domain        Microsoft DNS 6.0.6002
80/tcp   open     http          Microsoft IIS httpd 7.0
110/tcp  filtered pop3
143/tcp  filtered imap
443/tcp  open     ssl/http      Microsoft IIS httpd 7.0
663/tcp  filtered unknown
987/tcp  open     ssl/http      Microsoft IIS httpd 7.0
3389/tcp open     microsoft-rdp Microsoft Terminal Service
4125/tcp filtered rww
Service Info: OS: Windows

Service detection performed. Please report any incorrect results at
http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 346.09 seconds

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