Re: Bug in nmap 5.20 (nsock_core.c:516: handle_write_result)

[David Fifield <david () bamsoftware com>]

On Wed, Jan 20, 2010 at 11:23:35PM -0700, David Fifield wrote:
> On Wed, Jan 20, 2010 at 10:57:13PM +0200, pyllyukko wrote:
> > So I downloaded the brand new nmap 5.20 and set off to scan my lan. nmap  
> > suddenly crashed stating: "nmap: nsock_core.c:516: handle_write_result:  
> > Assertion `bytesleft > 0' failed".
> >
> > I briefly tried to debug it, and narrowed down the cause.
> >
> > Here's the exact command used, it's 100% reproducible (on my system, that 
> > is):
> > nmap -sS --script http-userdir-enum.nse --script-args=unsafe=1 - 
> > --script-trace -PR -T 4 -p80 -oA 192.168.0.2-%Y%m%d%R-debug -d9 - 
> > --log-errors --reason -R 192.168.0.2
> >
> > Here's the last few lines of the debug output:
> > NSOCK (0.1860s) Write request for 149 bytes to IOD #3 EID 91  
> > [192.168.0.2:80]
> > NSOCK (0.1860s) nsock_loop() started (timeout=50ms). 1 events pending
> > NSOCK (0.1860s) Callback: WRITE SUCCESS for EID 91 [192.168.0.2:80]
> > NSE: TCP 192.168.0.35:37821 > 192.168.0.2:80 | CLOSE
> > NSE: Received only 0 of 1 expected reponses.
> > Decreasing max pipelined requests to 0.
> > NSOCK (0.1870s) TCP connection requested to 192.168.0.2:80 (IOD #4) EID 96
> > NSOCK (0.1870s) nsock_loop() started (timeout=50ms). 1 events pending
> > NSOCK (0.1870s) Callback: CONNECT SUCCESS for EID 96 [192.168.0.2:80]
> > NSE: TCP 192.168.0.35:37822 > 192.168.0.2:80 | CONNECT
> > NSE: TCP 192.168.0.35:37822 > 192.168.0.2:80 |
> > NSOCK (0.1870s) Write request for 0 bytes to IOD #4 EID 107  
> > [192.168.0.2:80]:
> > nmap: nsock_core.c:516: handle_write_result: Assertion `bytesleft > 0'  
> > failed.
> > NSOCK (0.1880s) nsock_loop() started (timeout=50ms). 1 events pending
> >
> > Now what?-)
>
> Thanks. Brandon Enright found this bug today too. It has to do with
> recent changes to the http library. What's happening is there is an
> error getting the first pipeline response, and so the code erroneously
> reduces the pipeline capacity to 0, when it really should bail out. It
> then tries to do a zero-byte write, which causes the assertion failure.

I think this is solved now. There were a few related problems. First,
the HTTP server was sending a body in response to a HEAD request, which
violates the protocol standard. Of course that shouldn't cause Nmap to
crash, but this won't happen against servers that handle HEAD properly.

A second problem was that the HTTP pipeline code didn't handle its first
round of pipelining properly. When it determined that a server didn't
support pipelining, it would set its pipeline limit to 1, but it didn't
check this limit until once through the loop, so it would send 2
requests on the first connection. (It was off by one in all cases; for
example it would send 41 requests the first time if the server
advertised 40, but the case of 1 had the worst result.)

This interacted badly with another bug, which I think was my fault,
where the pipeline limit could be adjusted down to 0. In this case the
code would try to do a zero-byte write, which tripped an assertion
falure in Nsock. (Which is a separate issue.)

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