Re: bug in svn 17300

[David Fifield <david () bamsoftware com>]

On Thu, May 06, 2010 at 09:04:35AM -0500, Daniel Miller wrote:
> On 05/04/2010 01:38 PM, David Fifield wrote:
> > On Thu, Apr 15, 2010 at 10:32:02AM -0600, David Fifield wrote:
> >    
> > > On Wed, Apr 14, 2010 at 02:07:05PM -0500, Daniel Miller wrote:
> > >      
> > > > Not sure what's going on, but it seems consistent. Run as "sudo nmap -oA
> > > > nmap.7300.err -d --log-errors --script-trace --packet-trace -v -A -sU
> > > > 192.168.1.0/24". Error is "Unexpected error in NSE_TYPE_READ callback.
> > > > Error code: 71 (Protocol error)".
> > > >
> > > > Packet capture shows an ICMP error from the target, "IP header bad".
> > > >
> > > > I have attached the following:
> > > >
> > > > nmap.17300.err.output - last 200 or so lines of output
> > > > nmap.17300.err.nmap - regular output file
> > > > nmap.17300.err.xml - XML output
> > > > nmap.17300.pcap - packet capture of the host and port
> > > > (192.168.1.20:5000) conversation
> > > >        
> > > This is very interesting. It will be pretty easy to fix, because this is
> > > just an error response that no one has seen or reported before. All we
> > > need to do is add a handler for EPROTO in service_scan.cc.
> > >
> > > I'm kind of curious to find out how this could happen. As you noted, a
> > > type-12 ICMP error ("Parameter problem") is coming back in response to
> > > the Sqlping version probe. It doesn't look like there's anything wrong
> > > with the probe to me. My conjecture is that an active IPS or some other
> > > mechanism is forging the ICMP error. There's a Snort rule that catches
> > > the Sqlping probe: http://www.snort.org/search/sid/2049.
> > >
> > > Try changing this line of nmap-service-probes:
> > >
> > > Probe UDP Sqlping q|\x02|
> > >
> > > to this:
> > >
> > > Probe UDP Sqlping q|\x03|
> > >
> > > And see if it still happens. This is just a test of my conjecture and
> > > you should change it back afterwards.
> > >      
> > Have you had a chance to try this? What was the result?
> >    
> Sorry for the delay, been pretty busy. Tried the original scan again  
> with build 17475, same error. Changing the Sqlping probe to |\x03|  
> allowed me to finish the scan. I didn't get a packet capture, but I  
> might be able to in the next week or so if you need. What kind of info  
> do you still need to address the issue?

Thanks, that confirms my suspicion. Changing the probe was probably
enough to avoid triggering whatever IDS rule was causing the bogus ICMP
response to be sent. Anyway, I've added EPROTO to the list of known
error code (that won't cause Nmap to abort) in r17488.

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