Re: Should nmap.set_port_version support name_confidence?

[David Fifield <david () bamsoftware com>]

On Fri, Oct 24, 2008 at 11:03:27PM -0500, Kris Katterjohn wrote:
> On 10/24/2008 07:54 PM, Brandon Enright wrote:
> > On Fri, 24 Oct 2008 18:47:13 -0600
> > David Fifield <david () bamsoftware com> wrote:
> > > However, the setting of confidence and fingerprint appears to have no
> > > effect. l_set_port_version in nse_nmaplib.cc doesn't read either of
> > > these fields. (It has old code to read fingerprint, but it's commented
> > > out.) Later in the function Port::setServiceProbeResults is called
> > > with a fingerprint of NULL, which is the same as if the fingerprint
> > > field had been nil, so that line has no effect.
> >
> > > The line setting confidence doesn't work, for one thing, because Nmap
> > > calls that field name_confidence.
> > > http://nmap.org/book/nse-api.html#scripting-tbl-port-version-values
> > > But l_set_port_version doesn't look at name_confidence either.
> >
> > > Should it? Is its omission just an oversight? Does anything weird
> > > happen if a service is hardmatched with a confidence of 0 (in XML
> > > output or something)?
> >
> > Hmm, I don't even remember where I found the port.version.confidence
> > and port.version.fingerprint options.  I probably looked at another
> > script or some of our original NSE docs.
> >
> > ...fingerprint = nil should probably be deleted and the field always
> > set to NULL like you describe.  I rarely look at the confidence in XML
> > but since we have it, scripts should be able to set it.
>
> I think that if it's not too much trouble, support for setting both the
> fingerprint and confidence should be there, even though I too rarely pay much
> attention to confidence.

I looked at this more closely and it appears that name_confidence is
always set implictly based on the probestate. See
Port::getServiceDeductions in portlist.cc. If it's hardmatched or
softmatched then the confidence is set to 10. name_confidence is acting
like a function whose value is derived from the other service detection
values. So I'm leaving it alone.

David Fifield

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