Re: XML Output Inconsistency

[David Fifield <david () bamsoftware com>]

On Fri, Apr 30, 2010 at 12:05:40AM -0700, Fyodor wrote:
> Hi folks.  I've noticed an inconsistency in the Nmap XML output which
> I consider a bug, and I figured I might as well document it here.  But
> of course feel free to disagree if you think this behavior is
> desirable for some reason.
>
> To reproduce it, I start with an ncat running on port 3389
> (ms-term-serv per nmap-services):
>
> ncat -l -k localhost 3389
>
> Then from another window I run:
>
> nmap -oA /t/crap/nmaptst -p 3389 localhost
>
> The normal output includes this:
>
> PORT     STATE SERVICE
> 3389/tcp open  ms-term-serv
>
> And the XML output includes this entry:
>
>   <port protocol="tcp" portid="3389">
>    <state state="open" reason="syn-ack" reason_ttl="0"/>
>    <service name="ms-term-serv" method="table" conf="3" />
>   </port>
>
> Next I add version detection to the Nmap command:
>
> nmap -oA /t/crap/nmaptst2 -sV --version-light -p 3389 localhost
>
> This leads to the following in normal output:
>
> PORT     STATE SERVICE       VERSION
> 3389/tcp open  ms-term-serv?
>
> And in XML:
>
>   <port protocol="tcp" portid="3389">
>     <state state="open" reason="syn-ack" reason_ttl="0"/>
>   </port>
>
> Note that there is no <service> entry for 3389 any more.  If version
> detection had succeeded, it would have added a 'method="probed"
> conf="10"' entry.  But given that vscan failed, I think we should
> still fall back on the table lookup with conf 3 like we had before.

I can reproduce this. I checked and it doesn't happen (i.e., you get the
service element in either case) with 4.76.

The proximate cause was r12396. This revision was to make sure that an
ssl tunnel was recorded if detected, even if the service wasn't
identified through the tunnel. It did this by removing a condition (the
presence of a service fingerprint) around a call to
setServiceProbeResults.

This change had the side effect of making sure a serviceDeductions was
allocated for every port, whether service detection was successful or
not. The presence of a serviceDeductions (with a NULL name) inhibited
some later code that did the service name lookup specially for XML
output.

Reverting r12396 isn't right, because that fixed a real bug. Instead, in
r17423 I made it so that a table lookup happens in
setServiceProbeResults when the match is PROBESTATE_FINISHED_NOMATCH
(previously it only happened for PROBESTATE_EXCLUDED). I also bumped up
the confidence in the table match from 2 to 3; this matches the
confidence of table lookups without service detection, and matches the
later lookup that happened in Nmap 4.76.

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