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

[David Fifield <david () bamsoftware com>]

On Wed, Jan 20, 2010 at 05:24:47PM -0500, Jon Kibler wrote:
> David Fifield wrote:
> > On Tue, Jan 19, 2010 at 04:40:19PM -0500, Jon Kibler wrote:
> > > 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:

I've found the cause of this and it is fixed in r16535.

The bug was indeed related to the Port memory reduction I did. Formerly,
every port, whether it received a response or not, was allocated a Port
object at the end of the port scan by PortList::addPort, which also set
the port's state. Thereafter, functions like
PortList::setServiceProbeResults could rely on the Port object being
there with a state already set. Now, ports don't automatically get a
Port object, but allocate one on demand the first time a function like
PortList::addPort or PortList::setServiceProbeResults is called.
However, none of these functions aside from addPort set the state of the
Port object, leaving it PORT_UNKNOWN.

PORT_UNKNOWN is used as a special magic value in the functions that
handle port output. Its interaction with the logic for ignored ports was
the reason why different numbers of scanned ports had different
behavior.

I fixed the problem by having Port objects inherit the default port
state when they are created.

Because the defect needs a port to have received no response during the
port scan and yet still have been subject to version scan, this coudl
only happen with -sU -sV, and not, for example, -sS -sV. There may be
other cases where it could happen. A crash was likely with -sU -sV, and
even without the crash, you would still get the erroneous
"unknown"/"unknown-response" output.

Jon, your tests and packet traces were useful in solving this.

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