Re: nmap crash -- NmapOutputTable.cc:153: void NmapOutputTable::addItem(unsigned int, unsigned int, bool, const char*, int): Assertion `row < numRows' failed.

[Jon Kibler <Jon.Kibler () aset com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Fifield wrote:
> On Tue, Jan 19, 2010 at 04:40:19PM -0500, Jon Kibler wrote:
> > David Fifield wrote:
> > > On Mon, Jan 18, 2010 at 01:01:32PM -0500, Jon Kibler wrote:
> > > > Jon Kibler wrote:
> > > > > I am having nmap crash and getting empty files for output:
> > > > >
> > > > > > # nmap -sS -sV -sU -sC -oA cts -O -p- -T4 --min-rtt-timeout=1 --max-rtt-timeout=8 --initial-rtt-timeout=4 
> > > > > > --min-parallelism=64 --max-parallelism=128 --max-retries=3 --version-light 10.22.149.132
> > > > > > WARNING: You specified a round-trip time timeout (8 ms) that is EXTRAORDINARILY SMALL.  Accuracy may suffer.
> > > > > > Starting Nmap 5.10BETA2 ( http://nmap.org ) at 2010-01-16 21:48 GMT
> > > > > > Nmap scan report for 10.22.149.132
> > > > > > Host is up (0.00042s latency).
> > > > > > Not shown: 65533 open|filtered ports, 65526 filtered ports
> > > > > > nmap: NmapOutputTable.cc:153: void NmapOutputTable::addItem(unsigned int, unsigned int, bool, const char*, int): 
> > > > > > Assertion `row < numRows' failed.
> > > > > > Aborted
> > > > I hate to respond to my own email... but I notice that this had been a
> > > > problem that was previously fixed in 4.01.
> > > >
> > > > I have rerun the scan with -d, and it doesn't seem to tell anything not
> > > > already known (attaching log... if it passes filter).
> > > >
> > > > What can I do to help get this debugged?
> > > See if you can simplify the command line and still get the crash. For
> > > example, does it still happen if you don't use -sV? What if you narrow
> > > the port range with -p? The most likely culprits are the options that
> > > add rows to the ports table: -sS -sU -sC. If you can rule any of those
> > > out it would help.
> > I was able to narrow down the problem. I got it so that it only occurs
> > on a sU+sV on a relatively small number of ports. I have included pcap
> > files (tshark) of the successful and failed scans, as well as nmap debug
> > logs.
> >
> > More specifically...
> > # fails
> > $ nmap -sV -sU -d -p160-688 -T4  --min-rtt-timeout=1 --max-rtt-timeout=8
> > - --initial-rtt-timeout=4 --min-parallelism=64 --max-parallelism=128
> > - --max-retries=3 --version-light 10.22.149.132 >
> > nmap-sU-sV-p160-688.log 2>&1
> >
> > # works
> > $ nmap -sV -sU -d -p160-672 -T4  --min-rtt-timeout=1 --max-rtt-timeout=8
> > - --initial-rtt-timeout=4 --min-parallelism=64 --max-parallelism=128
> > - --max-retries=3 --version-light 10.22.149.132 >
> > nmap-sU-sV-p160-672.log 2>&1
>
> Thank you for the logs. This is strange. The target sent back the same
> responses in both packet captures--none of the additional ports 673-688
> should have been able to make a difference. Also strange is this:
>
> > $ nmap -sV -sU -d -p160-672 -T4  --min-rtt-timeout=1 --max-rtt-timeout=8 --initial-rtt-timeout=4 
> > --min-parallelism=64 --max-parallelism=128 --max-retries=3 --version-light 10.22.149.132
> > Host is up, received arp-response (0.00050s latency).
> > Scanned at 2010-01-19 21:23:36 GMT for 86s
> > PORT    STATE   SERVICE         REASON           VERSION
> > 160/udp unknown sgmp-traps      unknown-response
> > 161/udp open    snmp            udp-response     net-snmp
> > 162/udp unknown snmptrap        unknown-response
> > 163/udp unknown cmip-man        unknown-response
>
> STATE=unknown shouldn't happen. Same with REASON=unknown-response. This
> may well be a bug in the memory reduction changes I made. Every port
> that didn't get a response shares a single Port object, so an error
> could manifest itself this way.
>
> I can't reproduce this, though. Your scan that failed showed that the
> ports were properly detected open|filtered and not unknown:
>
> > $ nmap -sV -sU -d -p160-688 -T4  --min-rtt-timeout=1 --max-rtt-timeout=8 --initial-rtt-timeout=4 
> > --min-parallelism=64 --max-parallelism=128 --max-retries=3 --version-light 10.22.149.132
> > Nmap scan report for 10.22.149.132
> > nmap: NmapOutputTable.cc:153: void NmapOutputTable::addItem(unsigned int, unsigned int, bool, const char*, int): 
> > Assertion `row < numRows' failed.
> > Host is up, received arp-response (0.00062s latency).
> > Scanned at 2010-01-19 21:19:04 GMT for 92s
> > Not shown: 528 open|filtered ports
>
> Perhaps it does have something to do with the timing options. Possibly
> some code is not getting a chance to run. Try your above scans again,
> only this time use -T3 and the default timing and parallelism. Do each
> scan three times to see if the results are consistent.
>
> If the error only happens with short timeouts and high parallelism,
> we'll know where to start looking next.
>
> David Fifield


No real difference.

I should note that the one think may be related to the assert is that
when you reach 512 'unknown-response' messages, it croaks. However, I
would like to know why I am getting the 'unknown-response' errors.

Please see attachments!

Jon Kibler
- --
Jon R. Kibler
Chief Technical Officer
Advanced Systems Engineering Technology, Inc.
Charleston, SC  USA
o/c/s: 843-849-8214 / 843-813-2924 / 843-564-4224
e: Jon.Kibler () aset com or Jon.R.Kibler () gmail com
s: JonRKibler
http://www.linkedin.com/in/jonrkibler

My PGP Fingerprint is:
BAA2 1F2C 5543 5D25 4636 A392 515C 5045 CF39 4253


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

iEYEARECAAYFAktXgq8ACgkQUVxQRc85QlOFcwCgl49vqmV9ZGIxU1ZiOJkMmoQZ
8T8AnjuA0BraA4/jiLn0KjODPJsoL8Q+
=rSgs
-----END PGP SIGNATURE-----

===========================================================================
WARNING! This e-mail has been altered by TRUSTEM.COM's Email Filtering Service.
         The following paragraphs indicate the actual changes made.
         For more information about TRUSTEM.COM's filtering policy,
         please contact:
                Postmaster <postmaster () mail trustem net>.

NOTICE: The attachment originally called 'nmap.sh' constituted a security
        hazard and was renamed to 'DaNgErOuS.binary'

WARNING! Do NOT access this attachment unless:
  1) You were expecting this user to send you an email with an attachment.
  2) You verify that the name of the attachment you were expecting is: nmap.sh

If it appears that this attachment may be bogus, please report it to 
TRUSTEM.COM as it may be a new email virus. You can contact TRUSTEM.COM at:
        http://www.trustem.com/Contact_Us.php

TO ACCESS THIS ATTACHMENT AS ORIGINALLY NAMED:
  1) Right-click on the attachment 'DaNgErOuS.binary' and
  2) Save As: 'nmap.sh'

THANK YOU for helping us keep your email secure!

Attachment: nmap-sU-sV-p160-688.T3.tshark
Description:

Starting Nmap 5.10BETA2 ( http://nmap.org ) at 2010-01-20 18:55 GMT
--------------- Timing report ---------------
  hostgroups: min 1, max 100000
  rtt-timeouts: init 1000, min 100, max 10000
  max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
  parallelism: min 0, max 0
  max-retries: 3, host-timeout: 0
  min-rate: 0, max-rate: 0
---------------------------------------------
NSE: Loaded 4 scripts for scanning.
Initiating ARP Ping Scan at 18:55
Scanning 10.22.149.132 [1 port]
Packet capture filter (device eth0): arp and arp[18:4] = 0x00096BB7 and arp[22:2] = 0x3D13
Completed ARP Ping Scan at 18:55, 0.01s elapsed (1 total hosts)
Overall sending rates: 77.85 packets / s, 3269.75 bytes / s.
mass_rdns: Using DNS server 171.70.168.183
mass_rdns: Using DNS server 171.68.226.120
Initiating Parallel DNS resolution of 1 host. at 18:55
mass_rdns: 0.00s 0/1 [#: 2, OK: 0, NX: 0, DR: 0, SF: 0, TR: 1]
Completed Parallel DNS resolution of 1 host. at 18:55, 0.00s elapsed
DNS resolution of 1 IPs took 0.00s. Mode: Async [#: 2, OK: 1, NX: 0, DR: 0, SF: 0, TR: 1, CN: 0]
Initiating UDP Scan at 18:55
Scanning albliu-lago1.cisco.com (10.22.149.132) [529 ports]
Packet capture filter (device eth0): dst host 10.22.149.129 and (icmp or ((tcp or udp or sctp) and (src host 
10.22.149.132)))
Discovered open port 161/udp on 10.22.149.132
Completed UDP Scan at 18:55, 6.90s elapsed (529 total ports)
Overall sending rates: 153.14 packets / s, 4361.30 bytes / s.
Initiating Service scan at 18:55
Scanning 529 services on albliu-lago1.cisco.com (10.22.149.132)
Service scan Timing: About 11.34% done; ETC: 19:00 (0:04:34 remaining)
Service scan Timing: About 22.68% done; ETC: 19:00 (0:03:42 remaining)
Service scan Timing: About 34.03% done; ETC: 19:00 (0:03:04 remaining)
Service scan Timing: About 45.37% done; ETC: 18:59 (0:02:31 remaining)
Service scan Timing: About 56.71% done; ETC: 18:59 (0:01:58 remaining)
Service scan Timing: About 68.05% done; ETC: 18:59 (0:01:27 remaining)
Service scan Timing: About 79.21% done; ETC: 18:59 (0:00:56 remaining)
Completed Service scan at 18:59, 270.05s elapsed (529 services on 1 host)
Starting RPC scan against albliu-lago1.cisco.com (10.22.149.132)
NSE: Script scanning 10.22.149.132.
NSE: Script Scanning completed.
Nmap scan report for albliu-lago1.cisco.com (10.22.149.132)
nmap: NmapOutputTable.cc:153: void NmapOutputTable::addItem(unsigned int, unsigned int, bool, const char*, int): 
Assertion `row < numRows' failed.
Host is up, received arp-response (0.00052s latency).
Scanned at 2010-01-20 18:55:16 GMT for 277s
Not shown: 528 open|filtered ports

 nmap -sV -sU -d -p160-688 -T3 --max-retries=3 --version-light 10.22.149.132 > cts-p160-688-sV-sU-T3.log 2>&1

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